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
