Question about an "obscure" comment in the Reference (mut VS const)

In this rust doc: Statements - The Rust Reference

I can read "let (mut v, w) = (vec![1, 2, 3], 42); // The bindings may be mut or const"

The alternative of "let mut" is just "let" ("let const" is a compilation error).

In the comment they use "const" as an alternative to "mut" (which hold true in the context of raw pointers).

But, again in the context of let, are they using "const" in this sentence because there is no alternative (the sentence couldn't simply end in "or" like this: "The bindings may be mut or") or, deep down the language, a "let" is in reality a "let const"?

What I'm really asking is whether at some level of the compiler's internal representation, there might actually be an explicit "const" marker that gets added to non-mut bindings. What appears as just "let" in source code could internally be represented with an explicit immutability marker (const).

Personally, I think that when it mentions const in the context of "as opposed to mut", it just means that it is a non-mutable variable. I believe they used this because it is better that "non-mut". I really don't think there's a secret const in LLVM or something.

Hope this helps!

Like @cornix said its just the opposite of mut (which like you said is merely let a =... or the like). Most people know the term const because thats how C++ handles it (mutable default with optional const, as opposed to immutable by default with optional mut).

2 Likes

That's my take.

All implementation-detail considerations in my view.

If you don't have mut, you can't overwrite or reinitialize the variable or take a &mut _ to the variable. The compiler has to track which variables have those restrictions and which do not so it can error when appropriate. But how that's done isn't terribly relevant to programmers of Rust.

If the compiler is adding extra LLVM annotations or whatever that are only possible due to the lack of overwriting et cetra, it has the ability to do so for mut bindings too, since it's already checking if you actually needed the mut.

I discover something else: The FLS (FLS — FLS) has the same problem. They can say "mutable binding" but for some reason they can't say "immutable binding" (there is no "immutable binding" in the FLS).

Yes, you prove my point. How strange is this? People on reddit are talking about it a enum called Mutability.