I’ve considered myself a Julian for about 6 months now. I have enough experience to know that
a < b & c < d is parsed as
a < (b & c) < d and not as most would probably expect. And yet this bug (see comment below) bit me hard today.
This illustrates the problem, although it is very unlike my actual code:
x = collect(1:10) a = x[x.%3 .== 1 .& iseven.(x)] # wrong b = x[(x.%3 .== 1) .& iseven.(x)] # parens are required because of precedence of & println(a) # [3, 4, 9, 10] println(b) # [4, 10]
I think I was so focused on getting all the broadcast dots in place in my vectorized code that I forgot about the bitwise operator precedence, even though I use it correctly elsewhere. The problematic line looks so RIGHT that I failed to notice the error even after scanning it multiple times.
But the main problem is this: when you make this error, your code fails silently.
This is a massive gotcha, especially for people with a Matlab background who do this routinely. I understand that breaking syntax changes are very unwelcome so close to v1.0, but I really think this needs to be addressed somehow. The current precedences are arguably correct for bitwise operators, but are bugged when used as logical operators. So maybe we need to distinguish between these uses?
There is a longstanding issue (#5187) in which this is discussed in detail. There are many interesting ideas there, but it was eventually closed without a resolution. Is there still hope of doing something about it?