Hacker News Reader

Comment by JulianMorrison | Hacker News Reader

> 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

Then the globals can be defined with "val".

View on HN

No need to invent a new keyword, it is ok to just use "const": https://github.com/go101/go101/wiki/An-immutable-value-propo...

No, they are very different conceptually.

- A const is an abstracted value.

- A variable is an allocated piece of memory.

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.

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

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

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.

Concepts are defined as needed.

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

- that proposal would muddy the distinction.

Yes, they are different, const values doesn't allocated in memory NOW. But who cares? Most gophers just think const values are immutable values.

I mean we could let some const values allocated in memory.

Thankfully the people who make Go do care about conceptual muddles.

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.

Fair point. "value" and "var" then, perhaps?

perhaps, the real details would get hammered out in a proposal.

How about `mut var`?

Edit: this likely wouldn’t fly as it would be completely backwards incompatible

the val and const cases should hardly be different if the compiler has constant folding, except maybe for the typing.

From the language reference

> Constant expressions may contain only constant operands and are evaluated at compile time.

and a "const" can only be defined with a constant expression.

So the difference would be that a "val" can be assigned a value that is evaluated at runtime.

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.

if it is not constant, it must be variable i.e. changing. Mutation = change.

def plusOne(x: Int) { val y = x + 1; return y }

In the line of code above, `y` is an immutable variable. It does not mutate, yet it "varies" as different values of x come in.

No. A variable in mathematics does not change (mutate). And yet it is not a constant.

You’re thinking inside the imperative programming box.

Reply on news.ycombinator.com