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ₜ, 1) && j <= size(n_eₜ, 2) # Karniadakis coefficients cₜ, cₜ₋₁, cₜ₋₂ = 18/11, 9/11, 2/11 cᵣₕₛ = 6/11 # Electron update n_eₜ₊₁[i, j] = cₜ * n_eₜ[i, j] - cₜ₋₁ * n_eₜ₋₁[i, j] + cₜ₋₂ * n_eₜ₋₂[i, j] + Δt * cᵣₕₛ * (3 * e_rhsₜ[i, j] - 3 * e_rhsₜ₋₁[i, j] + e_rhsₜ₋₂[i, j]) - Δt * cᵣₕₛ * ν_perp * ∇⁴nₑ[i, j] end end and it seems to only compute the first line for some reason, i had buggy code for weeks because of this and I only found it by comparing the implementation to a CPU implementation with regular for loops. Wasted far too much time looking for bugs in my codebase when this was the issue. :face_with_steam_from_nose: Doing it instead the following way seems to fix it: 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ₜ, 1) && j <= size(n_eₜ, 2) # Karniadakis coefficients cₜ, cₜ₋₁, cₜ₋₂ = 18/11, 9/11, 2/11 cᵣₕₛ = 6/11 # Electron update n_eₜ₊₁[i, j] = cₜ * n_eₜ[i, j] - cₜ₋₁ * n_eₜ₋₁[i, j] + cₜ₋₂ * n_eₜ₋₂[i, j] n_eₜ₊₁[i, j] += Δt * cᵣₕₛ * (3 * e_rhsₜ[i, j] - 3 * e_rhsₜ₋₁[i, j] + e_rhsₜ₋₂[i, j]) n_eₜ₊₁[i, j] -= Δt * cᵣₕₛ * ν_perp * ∇⁴nₑ[i, j] end end Is this a well known bug? I hope they fix it soon, because this is the kind of thing one won’t see easily at all.

[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 check would be prone to have a lot of false positives and negatives, so the Julia compiler wouldn’t be the right place for it. It would be way too annoying to have the ocmpiler warn about such code in an hard-to-predict (because of the heuristics) way when the code is valid. That said, [image] bpsomu: at the very least, shouldn’t the Julia extension underline this as a potential issue? it would be nice to have it in some way as part of the extension. A warning for this was proposed as a github issue and rejected several years ago because it’s valid Julia syntax, but the Rust developer experience is so good precisely because tools like clippy warn about code even when it’s technically correct, if it’s a pattern that a lot of people make mistakes with. So if you can think of some good heuristics to detect this kind of code, it might be worth bringing it up in the Slack vscode channel. (Speaking of tools, do you use anything like the JuliaFormatter or Runic.jl ? I would think those would reformat this so the latter lines of the expression don’t have an indent, hinting at the issue even if they don’t directly explain it. )

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 this case: you don’t need to keep a trailing + in all lines, which is just another source of error.

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 Julia warn of this? at the very least, shouldn’t the Julia extension underline this as a potential issue? because as far as the compiler is concerned it looks at the expression a = b + c + d which it computes, but then it looks at the following line with + e it just ignores it and does not even return a warning. Can’t that be considered a bug?

[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 ever happen at this point.

[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 = MyStruct(0) MyStruct(0) julia> Base.:+(e::MyStruct) = e.x += 1 julia> + e 1 julia> + e 2 julia> e MyStruct(2) This is a bit of a contrived example, but wanted to show that just by reading the line without any runtime context you can’t say “this is not doing anything”.

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 (generic function with 1 method) julia> f(1,2,T()) hello, world 3

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 open a different thread to actually evaluate the role of these methods? Or is there a trivial reason for them to exist that I’m not considering?

[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 and have some suggestions for how it should work. Wonderful! We’re happy to have you here and help you learn the language and listen to your ideas! However, please be aware that “new” is a relative term. Yes, Julia is newer than, say, C, which was first created in 1972 and standardized in 1989. It is not, however, new in the sense that it is still being freely designed and changed in arbitrary ways. Julia development start…

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	25203	December 7, 2021
Syntax Surprises General Usage syntax , discussion , fun , gotchas	83	7400	January 21, 2023
A most harrowing collection of Julia WATs General Usage wat	106	14143	January 27, 2024
Multi-line expressions General Usage	5	3646	April 2, 2025
It is so nice to program in a sane language! Offtopic	50	4828	February 6, 2020

😤 Multi-line expressions aren't fully computed

Related topics