[mikepurvis]

Isn't that an implementation choice?

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.

[catlifeonmars]

> Like in C++, a const is absolutely allocated since you can get a pointer to one.

If I understand you correctly, you claim you can get a pointer to a Go const. This is not the case. For example, the following code will not compile:

const a int = 1

var b *int = &a

./prog.go:5:15: cannot take the address of a

See https://go.dev/play/p/QPxP-tF6qIs for a live example.

[mikepurvis]

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.

[catlifeonmars]

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++.

[JulianMorrison]

Yes, it is an implementation choice. I feel it's a choice that makes sense, too. But regardless, it's how things work right now in Go.