I had a KernelAbstractions.jl based Kernel function with a multi-line expression as below: using KernelAbstractions @kernel function karniadakis_update!( n_eₜ₊₁, n_eₜ, n_eₜ₋₁, n_eₜ₋₂, e_rhsₜ, e_rhsₜ₋₁, e_rhsₜ₋₂, ν_perp, ∇⁴nₑ ) i, j = @index(Global, NTuple) if i <= size(n_eₜ, …

[image] bpsomu: shouldn’t Julia warn of this? Since this is valid syntax, any detection mechanism that tries to check for (and warn about) this kind of thing would have to be heuristics based - like checking for lines beginning with a + or -, maybe checking the indentation, etc. Any such chec…

If you want to keep signs at the beginning of the line, and it’s always + or -, you could also do a = b + + c + - d which still follows the idea of “making the expression incomplete, to continue parsing in the following line”. But honestly I think that that parentheses are more robust in …

yeah, probably parentheses or using += are the right approaches here. The issue persists in regular Julia as well: a, b, c , d, e = 0, 2, 3, 4, 5 a = b + c + d + e println("a = $a") this prints a = 9 instead of a = 14 which I would have expected from my misunderstanding. However, shouldn’t J…

[image] bpsomu: Can’t that be considered a bug? What bug? I even tried to show this isn’t specific to Julia.

maybe bug is too strong a word for this. Isn’t this something for which a warning would be nice?

That’s something for a linter to do, but from a purely syntactical point of view you I don’t think there’s anything wrong. One might say that mandating the semicolon to terminate all expressions would avoid this, but the time for arguing this is long past, I don’t think such a breaking change would…

[image] bpsomu: but then it looks at the following line with + e it just ignores it and does not even return a warning. To add on this, from a purely syntactical point of view, that line might be doing something: julia> mutable struct MyStruct x::Int end julia> e = M…

The other issue is that this could be an effectful line depending on the type. Consider the following (ill-advised) code julia> struct T end julia> Base.:+(::T) = println("hello, world") julia> function f(a, b, c) x = a + b + c return x end f (gener…

I’m wondering if this prefix operators are actually needed though +(x::Number) = x *(x::Number) = x (&)(x::Integer) = x (|)(x::Integer) = x xor(x::Integer) = x As of now I can’t think of cases where they could be needed, and eliminating them would result in a MethodError. Could it be the case to o…

[image] VinceNeede: Or is there a trivial reason for them to exist that I’m not considering? Yes, there is: [image] PSA: Julia is not at that stage of development anymore Internals & Design You heard about this brand new exciting programming language called Julia a…

Those are unary methods, not exactly infix which by definition are binary . You can’t use * as a unary operator.

😤 Multi-line expressions aren't fully computed

General Usage

mbauman July 10, 2025, 2:51pm 13

Yes, there is:

Topic		Replies	Views
Best practice for avoiding line break bugs in long expressions General Usage	26	24858	December 7, 2021
Syntax Surprises General Usage syntax , discussion , fun , gotchas	83	6351	January 21, 2023
A most harrowing collection of Julia WATs General Usage wat	108	12829	January 27, 2024
Multi-line expressions General Usage	5	3458	April 2, 2025
It is so nice to program in a sane language! Offtopic	50	4390	February 6, 2020

😤 Multi-line expressions aren't fully computed

Related topics