Bool literals redefinition

Hi, shouldn’t this be disallowed, just to play on the safe side?

julia> function f()
           true = false
           return true
       end

julia> f()
false

Which version are you using? It should be a syntax error.

Sorry, it’s

Julia Version 0.5.0
Commit 3c9d753 (2016-09-19 18:14 UTC)
Platform Info:
  System: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Prescott)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, broadwell)

I don’t think we’ll get a lot of trouble by allowing this since it’ll be scoped but I believe it’s syntax error on 0.6.

OT: it seems that you might want a newer build or at least with a newer openblas…

Thanks, downloading v0.5.2 …

Indeed, in 0.6 it gives
ERROR: syntax: invalid assignment location "true"
just like if one tries to assign something to an integer literal.

Relatedly, assigning to where still works on 0.6.0-rc1. :smiley:

https://github.com/JuliaLang/julia/issues/20337

where is quite different. It is not a reference/literal that represent an object/variable so assigning a value to it have no affect on any normal usage of where. OTOH, changing the value of true and false could, though not really practically since I don’t think this is something one would accidentally do…

Allowing where to be used still as a variable could minimizing breakage, since it was allowed to be used as a variable in earlier versions. Obviously you can use it to create confusing looking code but that’s not at all a property of where.

1 Like

Good point, I hadn’t considered backwards compatibility issues. And thinking about it more, it would be good to keep it free for use as a variable name so long as it isn’t abused.

Right. Another way to put it is that we are not going to make wherewhere a syntax error and wherewhere where wherewhere where wherewhere is arguably worse than the cases in the issue…