Note that although sometimes possible, changing the value of a const variable is strongly discouraged, and is intended only for convenience during interactive use. Changing constants can cause various problems or unexpected behaviors. For instance, if a method references a constant and is already compiled before the constant is changed then it might keep using the old value
so it is not something that is encouraged, but nevertheless not ruled out because it can be useful during interactive development.
Also, when you reassign the first s1 in your example above, it is fine because
julia> "1" ≡ "1"
true
(strings are not mutable and you are not supposed to care about pointers).
Specifically, when you reload top-level code from a file, constants are redefined, often with the same value. Even when the value changes, it will usually also redefine all the functions that refer to those constants, so things will continue to work anyway. Disallowing this would make it essentially impossible to just reload top-level code that defines any constants, even though that’s really handy and currently perfectly possible with some warnings.
Sounds reasonable but would it be nicer if a constant is guaranteed to be a constant for non-interactive usage? Maybe we could allow mutation in Main only?
I typically define constants in modules. As long as I can reload a module (via Revise) to get the updates then I’m fine.
This is probably extremely minor in the grand scheme of things
I don’t really get the problem—if your code doesn’t produce any warnings, it’s fine. It seems like one should generally not be in the habit of writing production code that emits warnings. I suppose we could have a flag that turns any kind of language warning into an error.