> Alternatively, Go 2.0 could implement "frozen" global variables
A more general change would be to implement the "var" and "val" distinction that exists in some languages.
const x = 1 // x is a compile time alias for the untyped abstract number 1
var x := 1 // define x at runtime to be (int)1, x is mutable
val x := 1 // define x at runtime to be (int)1, x is immutable
Like in C++, a const is absolutely allocated since you can get a pointer to one. And then you can do horrible stuff like const_cast that pointer and mutate the value, and the possibility of that occurring prevents the compiler from doing certain const-related optimizations.
I'm not an active golang user, so it wasn't a comment on that, more just on the GP's assertion that a const had to be an abstracted value. It sounds like that is indeed the case in Go (an implementation choice), but more broadly, I wouldn't expect "const" to mean anything more to most programmers than "give me an error if I or anyone else try to modify this thing."
And in C++, it certainly isn't. Even a constexpr in C++ is a thing you can get a pointer-to— C++'s only guarantee with a constexpr is that it has to be possible to evaluate it at compile time.
Ah gotcha. Makes sense. The way I typically think of Go const is more akin to a typed macro, rather than a first class value reference where it is expanded in place. Notably, in Go constants cannot contain structs, arrays, so they have much less to do with mutability than in, say, in C++.
That wasn't exactly what I meant. What I meant was
- as of right now they are different, and clearly distinct, and it's actually important to unlearn thinking of a const as a var, because they don't do the same thing in practical terms
could be interesting, however I'd hope for something more visually distinctive that val/var as it took about 2-3 reads for me notice what was even the diff between L2 and L3.
I don’t understand why Scala chose “var” for mutable variables. A variable is not defined by being mutable—it is defined by being variable, i.e. not a constant. And it is immutable in math (where we don’t have to care about performance). So “val” is also a “var”, conceptually.
I think it was Fortran which introduced the equivalence between programming variables (that are a mutable piece of memory) and mathematical variables (which describe a relationship). But they aren't really the same. And "variable" has become too fixed in computer science usage to be repaired back to its earlier mathematical meaning.
A more general change would be to implement the "var" and "val" distinction that exists in some languages.
Then the globals can be defined with "val".