Rethinking the use of let for immutable bindings

[ImadRedwan]

I'd like to reopen a discussion around the use of let for immutable bindings in Carbon. While this has been touched on in Discussion #1497 and Issue #1578, those discussions are over two years old. Given the language and community have evolved since then, I believe it's worth re-evaluating this decision.

Summary

Carbon currently uses the following syntax:

let x: i32 = 42;
var y: i32 = 100;

Here, let defines an immutable binding, and var defines a mutable one. I'm proposing that const (or another clearer keyword) might be a better choice than let for immutable bindings, and that the community should revisit this part of the language design.

Why reconsider this?

1. Common expectations

• Since let is generally associated with variable definitions in many popular languages, it doesn't intuitively convey immutability or constant values. This can lead to confusion for users who expect a keyword that more explicitly signals that a binding is immutable. Using let for immutable bindings may therefore weaken clarity and go against common expectations around the concept of constants.
• Developers from C-family languages (e.g., C, C++, C#) often expect const to signify immutability, although it has already been criticized by carbon leaders
• New users without a background may not interpret let as meaning immutable.

2. Clarity and readability

• The keyword let is a verb, while other definition and declaration keywords (var, fn, ...) are nouns. This may make the keyword feel syntactically inconsistent, especially when considering future extensibility and teachability of the language.

What this discussion is not about

• This is not about const semantics at runtime or deep immutability.
• This is not about storage duration, pointers, or other low-level constness.

It is purely a discussion about naming: whether let is the best keyword to indicate immutability in source code.

Request for feedback

I'd like to hear your thoughts on:

• Whether let has caused confusion in your experience with Carbon.
• If const would make the code easier to read or teach.
• Whether now is the right time to revisit this topic formally.

If there’s enough support or interest, I’m happy to collaborate on a design proposal or work with others to take this further.

Thanks for considering.

[geoffromer]

Important point of clarification: let doesn't declare an immutable binding, it introduces a pattern match. By default bindings within the pattern are immutable, but that can be overridden by a var pattern or a ref binding (var at the start of a declaration is just a convenience shorthand for let var):

// `a` is an immutable value
let a: i32 = 0;

//`b` and `c` are immutable values
let (b: i32, c: i32) = (0, 0);

// `d` is an immutable value, but `e` is a mutable variable
let (d: i32, var e: i32) = (0, 0);

// `f` and `g` are mutable elements of an anonymous object
let var (f: i32, g: i32) = (0, 0);

// `h` is an immutable value, and `i` is a mutable reference to `g`
let (h: i32, ref i: i32) = (f, g);

I do think this has caused confusion, but I don't think changing the spelling of let will help, and changing it to something like const that signifies immutability could make the problem worse.

Note also that const already has a different meaning: like in C++, it's used to mark read-only access. So const Foo* is a pointer that cannot be used to mutate the object it points to (although the object itself may be mutable via other access paths). C++ uses const both to declare immutable objects and to mark read-only access paths, but that conflation has led to confusion, so we're trying to avoid it in Carbon.

I also don't think this question is ripe to revisit yet, because this whole area is still in flux. For example, we very recently introduced a val keyword to mark immutable return values. In principle that could also be applied to bindings (for example to make a binding immutable within a var pattern), but we're holding off on that because it's not clear if that's actually useful in practice.