[Proposal] Remove let declarations

[lattner]

Following on quite a bit of discussion about keyword naming, confusion about how immutability works with reference semantics, confusion between runtime constants and compile time constants, I think we should simplify Mojo by removing named immutable values (aka let declarations and the keyword) entirely. I wrote up a proposal here, I'd love to know what folks think about it:
https://github.com/modularml/mojo/blob/main/proposals/remove-let-decls.md

Note that this doesn't remove the notion of immutability entirely from Mojo, just let declarations, and a future lifetimes feature will include immutable references (which is critical for mutability^sharing checking), here's we're just talking about removing the let declaration. We've discussed it a bit internally to Modular and folks think this is a good idea, but I'd love to get questions and comments from y'all before doing anything here, thanks!

-Chris

[gabrieldemarmiesse]

Many thanks for this proposal!

I was initially against, but there were very good points in the proposal, so I'm in favor of this. It's also closer to Python, and if we wish, we can always take a look at it again once we have lifetimes and references, it will be much easier to understand the implications of bringing back let.

I wish there were ways to make some classes/structs immutables, notably when they have a __hash__ method, but maybe this can be solved by metaprogramming. Python's stdlib has many immutables classes (datetimes, tuples, uuid...) it would be good if there was a way to express it so that users don't try to set attributes, but maybe there is a trick I'm not seeing.
Python override __setattr__ to raise NotImplemented to express this, but I would prefer something that the compiler can understand.

[lattner]

I wish there were ways to make some classes/structs immutables, notably when they have a hash method

I think what you're looking for is "value semantics". Dave Abrahams often gives talks on this topic, which I highly recommend, here's a recent one aimed at C++ programmers if you're interested:
https://www.youtube.com/watch?v=QthAU-t3PQ4

Mojo already has all the mechanics to provide great support for this, we just haven't built out the stdlib to explore this yet.

[gabrieldemarmiesse]

I'll look at it. Awesome! Many thanks!

[nmsmith]

The proposal is to remove let, but I'd like to share some broader thoughts on let and var.

Over the last few months, I've slowly been working on a counter-proposal where we get rid of both let and var, and bind names using the syntax variable: Type = value, or variable := value when the type is inferred.

This syntax overlaps with Python's syntax for function-scoped variable declarations (and accordingly, function-scoped name binding), so at first glance it isn't compatible with the lexically-scoped variables that Mojo currently has. However, I think we can resolve this discrepancy. But to achieve that, we have to tweak how names are handled in Mojo. In particular, we have to remove variable shadowing. (But we can replace it with something very similar: name rebinding.)

In a def, variable declarations would work the same as it does in Python. But in a fn, variable declarations would be a strict subset of how it works in def. (i.e. if you paste the fn declarations into a def, they will work the same, but you can't necessarily paste def declarations into a fn.)

That said, it might be worth waiting until Mojo has references/pointers before changing how variable declarations work, because these features are deeply related, and they probably need to be co-designed. Otherwise, the syntax might need to be changed several times in succession.

I will share my proposal some time in the next few days.

• Edit: I've changed my mind on this. It seems better to wait until the dust settles on let before contemplating any changes to var.

[lattner]

Python already supports variable: Type = value with different semantics, and we want scoped declarations without an initializer, e.g.:

var x: String
if ...
  x = "foo"
else:
  x = "bar"

But regardless, it sounds like you're in favor of removing let :)

[nmsmith]

Yep, I'm aware of those constraints. I think we can adhere to them while still remaining consistent with Python.

[nmsmith]

But regardless, it sounds like you're in favor of removing let :)

I think let is a poor syntax for declaring non-reassignable variables, so yeah I'm in favour of removing it. But I think there's still a lot of value in being able to declare non-reassignable variables somehow. Mainly reading comprehension: if you know the value of a variable will never change (or even just the referent, in the case of Python objects), it's easy to understand what the symbol means when you encounter it throughout a function body—there's no need to inspect all uses of that variable to confirm that its value/referent hasn't changed between lines X and Y. This is useful when debugging. (And it's most useful when you have deep immutability, not just shallow immutability. For example, if you have a pointer variable it would be nice to know that neither pointer nor the object being pointed to will change.)

These are things worth considering as Mojo's design gets fleshed out. Personally, I think it's too early to make conclusions about the value of such a feature just yet. We'd need to wait until Mojo has references, at the very least. 🙂

But I dislike let as it stands, so I'm happy to see it disappear until a better syntax arises, if it ever does.

[richardkiss]

Note that python also supports

x: String

You don't see it much because it's essentially ignored by the compiler. But mypy picks it up. This means we could in theory get rid of var too.

[helehex]

If it doesn't help the compiler much, then let it be gone

[guidorice]

The proposal seems clear and, a good idea. As a student/learner of mojo: In practice, I cannot really see very often using let/var in def functions. In a def function I am thinking Python, and not writing let or var.

I would mainly be focusing using those in fn functions. It seems if let gets removed, then the meaning of var kind of falls away too- because of which semantics I'm opting in to with def or fn.

But again 👍🏽 on the proposal!

[melodyogonna]

I agree it should be gone, it's a bit disorienting as a Python programmer having to deal with these extra keywords just for variables. I would also argue to at least rename alias as well - Python has a syntax for defining type aliases.

[theopomies]

There is a difference with alias, the keyword is used for compile-time values, these include type aliases but are not limited to them, meaning you can also do

alias foo = get_foo()

and call a function at compile-time, if its body respects some constraints.

[melodyogonna]

@theopomies I do not think aliases should determine what is a compile-time value, Mojo already provides mechanisms for expressing comp-time values, and if it's necessary then whether a function is compile-time should be indicated at the point where the function is created, not where it's used. e.g

@comptime
fn some_function() -> Int:
     return 20 * 10

var x = some_function()

[ivellapillil]

@melodyogonna today already the following works in Mojo (try it out :-)).

fn some_function() -> Int:
     return 20 * 10

alias x = some_function()

fn main():
    print(x)

Which I find is excellent. AFAIU, Mojo's philosophy is that at comp time almost any code could be run. This means that it is at call site determined if it is comp time or not. Which IMHO is brilliant. Library authors do not have to plan ahead how their code is going to be used. This gives a lot of optimization options to the user of the library.

[mzaks]

I am a bit conflicted, maybe because I have a long history of writing Swift, where when declaring named variables I start with a let till I identify this variable needs to be mutated. I adopted this style in Mojo and it worked great for me.

I would say that generally let enhances readability, or rather reduces the mental load while hunting for bugs, except for the Pointer instances which are let declared even if underlining memory can be mutated. AFAIK the keyword itself has its root in functional programming, where mutable state is a "swear word". Mojo does not follow the pure function programming paradigms, but exposing mutable state and assuring immutability can be of great help, specifically when hunting a bug in a large system.

That said I do appreciate that Mojo has it's "roots" in Python and let is a new / foreign concept, which provides limited benefits. What I would appreciate if the let keyword will be dropped is semantic highlighting for immutable variables in IDE support. As far as I can tell it should be possible to identify immutable variables based on code flow analysis, maybe even show it correctly for Pointer variables, although that entails a much deeper flow analysis then just checking for assign statement and mutable method calls.

PS: does it mean that every variable would be inout passable to a function by default? Or rather we would not be able identify on the call sight that the var instance might be mutated by the function. If so, it would also be nice to have some semantic highlighting in the IDE for this. BTW, with semantic highlighting I mean one of the following: colorization, different font / typography style, hover and inlay hints.

[lattner]

Yes, I agree with you. The let keyword definitely has historical roots and I'm also pretty used to how things are done in swift :).

As far as I can tell it should be possible to identify immutable variables based on code flow analysis
Indeed, Mojo already has this implemented and warns you when you should use let instead of var. This is one reason why this is just redundant to the compiler.

PS: does it mean that every variable would be inout passable to a function by default?

No, definitely not. This is /just/ about about removing the let syntax, it does not changing argument passing or how inout works, and doesn't remove immutability from the language. For example you still couldn't call a mutating method on the result of a function (because the mutation would be disarded), e.g. YourType().someMutatingMethod() will still be rejected.

[theopomies]

I believe let is a necessary keyword for the type of work Mojo intends to take on, because many times it has allowed me to prevent bugs where I would have introduced mutability involuntarily, or without thinking it through.
The fact that I can decide that I will use it as a binding and not a variable and get an error when I try to mutate it allows me to think more carefully about what I'm trying to do with this data/value.

It is also essential that we have a way to prevent the use of inout arguments by default. I'd rather have the LSP tell me that I can't call a function unless the argument is mutable than have to debug understanding why my var that I believed behaved like a let because I was told "if you don't mutate it behaves like a let through statistical analysis" doesn't behave like a let because I passed it to a function that used inout instead of borrowed. I believe there should be a way of being warned against accidentally mutating, and that the let keyword is the way, for the same reasons that fn declarations use borrowed arguments by default and not mutable references like def declared functions.

This is only my humble opinion and there may also be other solutions to these issues than the let keyword, I might be skewed by what I've grown to use in other languages.

[theopomies]

@lattner Thanks for the answer, I agree with you that this is "just" a nice to have when you remain within the same context, or scope, but not necessary, after all we can simply not mutate it by being more careful.
But when dealing with calling a function with an inout argument, I do consider it more necessary than nice to have, unless, like & and &mut in Rust, or ^ already in Mojo, we get a way to explicitly define what behavior we expect at the call site. (EDIT: See PS)

I agree that this makes it harder for programmers that come from python and only python, but at the same time isn't the goal to also bring in the C(++) / CUDA / etc. devs to Mojo ? Shouldn't Mojo, even though it is a member of the python family, meet everyone in the middle? After all, this feature might be more useful to these types of devs for the correctness of critical parts of the software, rather than the python devs that can, if they prefer, stick to def and, soon, classes, while being able to call APIs coded with fn and let by their peers? And if they want to use fn and let declarations for their benefits, isn't the cognitive load still better that if they hade to code a FFI for C++ code ?

Still, I'm speaking from an obviously biased point of view, as I wish emphasis to be made on correctness than pure ease in Mojo, at least in fn which, to me, provides a more sane and pedantic default, but if you of all people suggest let should be removed, I must accept that I cannot fully grasp all its implications and simply accept that you must be right.

[nmsmith]

FWIW Chris isn't proposing that immutable arguments (the borrowed convention, which is the default) be removed. Those will continue to exist.

[theopomies]

@nmsmith Yes, but right now, if I create a let declaration and call a function with an inout argument, I get an error, which I expect and want to keep.
If we remove let declarations and only have var, code that would have errored previously would now compile, and I might not have realized that I might mutate my variable by making this call, I now have to check every function signature to make sure, when LSP support or just the compiler would previously have helped me prevent these kind of bugs

fn foo(inout s: S):
    pass

fn main():
    let s = S()
    foo(s) # errors, tells me that s should be mutable to be an inout argument, I now have the choice to make it mutable or use another function
    var ss = S()
    foo(ss) # No error

I'd argue that in the context where let doesn't exist, you (can) lose correctness and introduce more potential bugs with accidental mutability, because we programmers tend to make these kind of mistakes after some time

[mzaks]

Yeah this is also what I mean in my PS paragraph. And I guess if there will be some kind of a semantic highlighting for mutation, it’s kind of ok. But it will be kind of like pull vs push semantics. With explicit let, we push the compiler to error out if there is unintended mutation, where with semantic highlighting we need to explicitly “pull” / check if there was an unintended side effect.

[theopomies]

PS: it seems they address the topic of references and mutable references in the lifetimes proposal, so if that's the case, it does remove the necessity I see out of let for input arguments, but my opinion is I would still like the keyword to stay for the other use cases, even though it is not required

[strangemonad]

A few thoughts:

• Overall, I'm in favor of this simplification. It's confusing to have multiple forms of immutability and const-ness all interacting.
• The arguments in the proposal around safety and readability seem to possibly be over-indexed on local function scope? Being able to define module-level assignments that can't be changed is probably a place where reasoning about let-assignments adds more safety. Would you propose this be done by only allowing read access after module initialization and the module remains the owner after module initialization?
• I think I'd like to challenge your proposal for keeping var as is and suggest something that should feel at home to python folks. Consider the following.

class Person:
   name: str
   age: int

Person.name # AttributeError (ie name isn't a ClassVar)
Person.__attributes__  == {'name': str}

I think re-using this syntax in a local basic block would serve the purpose of local scoping in a way that would feel natural to many python devs. eg

quantity: int
if a:
  quantity == 0
elif b:
  quantity == 1

Both Pyright and Mypy can reason about type narrowing / type refinement in situations similar to this (e.g. starting with quantity: int | None = None and refining to quantity: int). Typescript and flow type refine similar situations with javascript undefined and I'm assuming Mojo could check for use before initialize at compile time in this situation.

[lattner]

Python already uses this syntax to mean something else, e.g. you can use x: int = 42 and even x: 4+5 = 7 (yes really, try it out ;-) but in any case it seems like you're in favor of removing let. As the proposal mentions, changes to var syntax can be considered separately.

[ivellapillil]

I am just wondering based on your answer. Are there any plans to do something of the following in Mojo? ;-)

def typestr(): return str

x: typestr() = "x"

[lattner]

That is valid python syntax, so in "full compatibility mode" (which hasn't been defined yet), we will need to accept and ignore it, along with other MyPy type annotations. Even "int" annotations are not useful to Mojo, because annotations mean "that type or a subclass".

[strangemonad]

@lattner sounds good and agreed the var syntax changes can be considered separately. I'm aware that any value can be used as a type annotation. I'm sure that's going to lead to all sorts of fun figuring out what's allowed expressions or aliases and parameters and whatever "comp-time" or "const-expr" phase that's considered to be :)

I just wanted to point out that for the explicit case you're mentioning, I believe Python already has the semantics you're proposing for var foo: Ty (variable declaration without assignment).

The following is valid python

def foo(undef: bool):
    s: str
    if undef:
        s = "defined"

    print(s)

foo(True) # -> defined
foo(False) # -> raises UnboundLocalError

Note that this is different than if you hadn't defined s:str at all, which would raise NameError instead of UnboundLocalError

[rarebreed]

I'm a bit torn. On one hand, while python doesn't have a concept of a const or immutable local named variable, that doesn't mean the need isn't there. Python is the only language I can think of that doesn't have const, final, readonly, val etc, to make a local immutable named variable.

There's a difference between python lacking the concept of immutability, and pythonistas wishing they had the feature. Long before I heard about functional programming and its preference for immutable variables, many times I wished python had some way to say "I can't reassign the value of this variable". All the more so due to python's lack of lexical scoping and confusing nonlocal keyword.

I also have my doubts it's going to be easier teaching that mojo has immutability for references/borrowed values but not for local named variables. Or rather, I think it might be easier for pythonistas. But once you dive into the system's programming aspect of mojo, and especially for people coming from languages like C++, rust, swift, I think it might actually be more confusing (C++ might be easier, since there's an explicit difference between a "const pointer", "pointer to a const", and a "const pointer to a const"). I had to think for a while about what the difference even was, and I'm not even sure my mental model is right.

On the other hand, if it makes the code simpler to reason about and is easier for pythonistas to learn, I think that takes a higher priority. In order for mojo to gain a foothold, the "target market" has to be python programmers. Unless a language wants to be niche, I think it has to be able to become (or assimilate with) the dominant leader given by the economic theory of Network Effect.

Also let is confusing in mojo right now (and for that matter, so is alias) so something needs to be done about it.

[lattner]

Right, I think Mojo also needs to be careful about trying to fix all the "nice to have" things that exist in other programming languages, and focus on actually-critical extensions that are aligned with its goals. There are tons of ideas in many other languages that could theoretically be put into Mojo, but doing so would destroy a lot of the value of Python - it is a relatively small and simple core language.

[Brian-M-J]

many times I wished python had some way to say "I can't reassign the value of this variable"

It does actually. I wrote a more verbose comment in this discussion explaining it. In short, look at:

• Passing frozen=True to the dataclass decorator.
• typing.Final
• typing.NamedTuple

[rarebreed]

Final is nice, but still a bit constrained. You can't use it in type declarations

def foo(age: Final[int]):  # "Final is not allowed in this context"
   ...

def bar() -> Final[int]:  # Final is not allowed in this context
    from random import randint
    return randint(1, 100)

But for purely local or top level variables, yeah it is nice, assuming your team is using a type checker like mypy or pylance.

dataclass(frozen=True) is nice, unless you need a __post_init__ which I find I often do. For example, if the value of a field is dependent on the value of an earlier field. It's odd they couldn't freeze it after the __post_init__

And NamedTuple seems to get "reinvented" a lot, eg the aforementioned dataclass types, attr, pydantic, etc. I'd even argue something like TypedDict (which isn't immutable per se) is similar to the rationale for wanting a NamedTuple. Also, for up to 3 elements, I find a regular old immutable tuple to be fine (beyond 3, I typically create a dataclass).

So this is why I said that while python doesn't natively have a good way to enforce immutability, it's definitely a recognized need within the python community for it.

[ivellapillil]

After thinking a bit about it, I agree let as it stands now confuses more than the benefit it brings, since it is only shallow immutable.

[Brian-M-J]

There is no performance benefit to the Swift/Rust design, and I personally haven’t seen any data that shows that there is any safety or readability benefit. If anything, it is the argument when seeing let x = foo() that you know x will never be reassigned, but any benefit here is small.

I agree with you that let shouldn't be used to indicate immutability, but as for the safety and readability benefits of non-reassignable variables, I think the Python community itself would disagree with you.

There are multiple ways to indicate a non-reassignable variable in Python:

• The Final decorator for type checkers to alert the programmer in case of reassignments.
• Passing frozen=True into the dataclass class decorator. This generates a run-time error (dataclasses.FrozenInstanceError) if you try to reassign a field of the class.
• The NamedTuple class also generates a run-time error (AttributeError: can't set attribute) if you try to reassign any of the fields of a class that inherits from it.

So clearly, there was enough of a demand for these particular semantics that there are 3 features in the language for them, with two of them being so strict that they produce run-time errors. If Mojo aims to be a superset of Python, why not add support for these features already present in Python? The readability benefits are especially present in situations where a variable is conditionally assigned with complex logic in between its declaration and assignment, rather than the toy example given above. It also prevents footguns like reassigning math.pi (imagine the havoc that would cause).

let and var can be made completely orthogonal to mutability (and its lack thereof) to simplify the language and make it so that there is one way (immutable references) to assign an immutable value to a variable. Maybe let and var can be used to indicate non-reassignable and reassignable variables and nothing more.

Due to ASAP destruction, CheckLifetimes has extra complexity to reject code like: “let x: Int; x = 1; use(x); x = 2; use(x)” even though the original lifetime of the first “x=1” naturally ended and “x” is uninitialized before being assigned to. This has always been a design smell, and it doesn't work right.

I honestly don't know how to balance the need for the above to work properly with the prevention of footguns that come with reassignment. The only idea I have right now is to only allow the reassignment of let variables if the lifetime of their previous value was explicitly ended with the ^ operator. At least then there would be a clear audit trail in case something goes wrong.

Edit: Now that the decision has been finalized, at least we can look at other languages that considered this (like Rust) and learn from them.

[nmsmith]

I've thought of a situation where not having let might lead to some performance bugs.

Mojo is planning to employ copy-on-write for its standard data structures (arrays, strings, dictionaries, etc.)

This means that statements of the form var b = a are supposed to be cheap, even when a is a multi-megabyte array, because the underlying data buffer is shared, rather than copied.

Typically, when you're passing around an array of this size, you don't want to be making deep copies willy-nilly. But with copy-on-write data structures, an operation as simple as b[0] = 0 can trigger a deep copy. In other words, although this looks like an O(1) operation that takes a few cycles, it might actually be O(N) and take 100,000 cycles instead. Being able to declare b using let rather than var is an iron-clad way of making sure that you don't accidentally trigger a deep copy like this.

That said, if your program accidentally mutates b when you weren't intending to, it's likely that you have a logic bug, not just a performance bug. Are there situations where you could trigger an unintentional deep copy without also having a logic bug in your program? I'm not sure.

[Brian-M-J]

Note that immutability and value semantics remain an important part of the Mojo design, this is just about removing "named immutable variables". Immutable references in particular are critical and will be part of a future "lifetimes" feature.

From what I understand, you will still be able to assign an immutable reference to a var variable, which would prevent the kind of bug you are talking about. Removing let would make sure that there is only one way to declare an immutable value, which simplifies the language.

I agree with Chris that it's a good idea to decouple let and var from specifying whether a value is immutable or mutable, but I would still like to keep let around to mean "a variable that can't be reassigned", just like the Final annotation in Python. It would make reasoning about code much easier as it shows the programmer's intent with a variable. You wouldn't have to go hunting around a particular scope to check if the variable still refers to the same object.

[nmsmith]

Oh, yes, I suppose you can write var b = ref a (or whatever the syntax will be) instead of var b = a if you don't intend to mutate b. That would be sufficient for handling CoW data types safely.

Though if people are encouraged to use this approach to pass around CoW types, then the standard CoW types may as well be non-Copyable, and instead require an explicit call to a clone() method to create a shallow copy (and bump the ref-count).

[Brian-M-J]

Though if people are encouraged to use this approach to pass around CoW types, then the standard CoW types may as well be non-Copyable

Making value/CoW types non-copyable sounds... so wrong.

and instead require an explicit call to a clone() method to create a shallow copy (and bump the ref-count).

Mojo already uses = to mean "copy", so I don't see the need for a clone method. Mojo can just do what Swift already does and optimize away unnecessary copies and allocations. (Mojo already does some of this e.g. optimizing a "copy + destroy" into a "move")

I think ref and mut only make sense for reference semantics and are unnecessary for value types. E.g. If you don't intend to mutate b just declare it as non-reassignable (using let or some other keyword) and assign it a value. According to the rules of value semantics, b is now a constant since you can't mutate a value and have to make a copy to hold a new value.

[nmsmith]

Mojo already uses = to mean "copy"

= doesn't mean copy. It means "obtain the value from the RHS", which might involve a move, a copy, or neither. The last behaviour occurs whenever the RHS is a function call: functions with return types that are not @register_passable are compiled such that they write directly to a memory location provided by the caller. (These functions have an extra hidden argument: the memory address to write to.)

I don't see the need for a clone method

Non-Copyable just means that the type can't be implicitly copied using a var b = a assignment operation, including when passing to an owned argument (which has the same semantics as var, hence the two keywords are likely to be unified). The purpose of having a clone method (and a Cloneable trait) is to make the act of copying explicit. This is important whenever copying is expensive, and it turns out that for CoW types, copying is expensive, because it requires a piece of shared memory to be mutated (the reference-count), which is very expensive if you're trying to use the value from multiple threads. (And given Mojo is foremost a programming language for writing parallel programs, manipulating CoW data types from multiple threads will be a common occurrence.)

[rarebreed]

I agree with the notion of something like a clone method, because as @nmsmith pointed out, the = operator does not imply copying, it is actually the assignment operator.

Since mojo is more flexible than rust by not requiring affine types (which forces all data types to be Moveable) there needs to be a way to handle "getting the value of the RHS" depending on whether the RHS is Copyable, Moveable or neither (might not be a bad idea to have a Pinned trait too if there isn't something like that already).

This was actually one of the more difficult concepts I found while teaching others rust. They asked how come in the code below, x is still available but a is not?

let x = 10;  // defaults to an i32 type
let y = x;  // x's value was copied to y, not moved/transferred, so it's still useable later
println!("x is still {x}");

let a = String::from("rarebreed");
let b = a;  // since a is a String, it doesn't implement the `Copy` trait
// println!("a is still {a}");  // fails to compile since a's value got moved to b and is no longer available
let b = a.clone();  // works

Since x is a simple type (equivalent to a register_passable), it automatically implements the Copy trait. a on the other hand is a String type and lives on the heap. It does not implement Copy, but it does implement Clone and therefore has a clone method. This is so that the programmer can decide:

• To just move/transfer the value from the RHS to the LHS
• To explicitly clone() it, if they still need the value of the RHS to be available, at the cost of performance
• Or use a different type altogether, like a Cow if it's mostly only going to be read from

When I told people learning rust that you have to know whether a data type implemented the Copy trait or not to tell the difference, they said that was confusing and required more work to understand the behavior. In practice, I found it not so bad, because the LSP/compiler would tell you when you were using a variable after its value had been moved.

[dderooy]

I really like this proposal. I'm coming from a full-time python background and this proposal allows for a cleaner mental model imo. I like to imagine all variables/data at the most basic level as mutable. Safety and immutability are constraints that can be applied afterwards.

If you own a house, you can change it however you like. If you rent a house, you can paint the walls and change things but the deed to the address is not yours. If you book the house for an event you cannot change anything. In all accounts its still just a house that is fundamentally changeable at any moment, but safety and immutability are contracts applied to it.

Pushing immutability to 'the world of borrowed arguments and immutable references' seems like a good fit and a natural next step for Mojo-Python.

[soraros]

-1. I think immutability granted by let is fundamental and not just a nice to have for a system programming language, and should be the default (don't be C++, please). The argument "Python doesn't have it" is not a good one, since Python is not a compiled/statically typed/system programming language at all. Having the compiler warn me about undesirable mutation with inout functions is something I refuse to give up.

[dderooy]

immutable let declarations != immutable references. The proposal says there will still be immutable references which will be tracked and enforced by the borrow checker.

[rarebreed]

As @dderooy pointed out, there will still be immutability, but through reference semantics rather than value semantics.

What's still a little confusing to me though, is that in rust, in order to have a mutable ref, you must have a mutable variable. Eg

let name = String::from("rarebreed");
let name_mut_ref = &mut name;  // fails to compile.  Can't take a mutable ref to an immutable var
let name_ref = &name;  // this is fine.  name_ref is an immutable reference since name is immutable

let mut name = String::from("rarebreed");
let name_mut_ref = &mut name;  // works now

So without immutable vars, I'm curious how mojo can make an immutable reference, when the referent itself cannot be declared immutable? At best, it would be the C++ equivalent of a "const pointer". You can't change where the reference is pointing, but you can change the value stored in the address the reference is pointing to.

I'd much rather have a "pointer to a const". I think it's generally more valuable to know that whatever thing the reference/pointer is pointing to can't be mutated...than to know I can't change the address the reference is looking at.

[dderooy]

Speculating but Mojos compiler could enforce immutability for a limited time as a contract for a mutable variable. The contract would expire with the reference lifecycle.

[soraros]

@rarebreed exactly, I don't know how to reasonably convey that a reference is not mutable. Maybe by using something like var r = mut/ref ...?

[rarebreed]

Speculating but Mojos compiler could enforce immutability for a limited time as a contract for a mutable variable. The contract would expire with the reference lifecycle.

Yeah, that's about the only way I can see it happening.

If there is a mutable variable, you can pass it to a function by borrowing it through an immutable reference. Inside the called function, the value can't be mutated. The compiler would also be able to check that no other threads are:

• borrowing the same referent mutably
• the parent thread for the lifetime of the borrowed refs in the child threads also doesn't mutate the value of the referent

I think the latter point is going to be confusing for everyone. Pythonistas and those with a system programming background. Pythonistas aren't familiar with immutable references at all (I can pass a dict to a function and mutate the values within), and system programmers will think, "oh, the referent is mutable, so I can mutate it in the parent thread".

So I'm a bit dubious that this dichotomy of no local/global immutable value semantics, but immutable reference semantics will be easier to teach.

But this is all conjecture on my part so far. I'd like to see the proposal fleshed out more on how exactly one can create an immutable reference from a mutable referent, and how this will play out in a multithreaded world (including the parent thread)

[rarebreed]

@lattner

I talked about this in an earlier comment thread, but I'd like to get some feedback on this question. After some more thinking, how can you take an immutable reference to a referent that is mutable? In rust for example, to have an immutable reference, the referent must also be immutable

let name = String::from("rarebreed");  // immutable local var
let name_mut_ref = &mut name;  // fails to compile.  Can't take a mutable ref to an immutable var
let name_ref = &name;  // this is fine.  name_ref is an immutable reference since name is immutable

let mut name = String::from("rarebreed");
let name_mut_ref = &mut name;  // works now, because referent is mutable, so I can take a mutable ref

One way I can see how to take an immutable reference from a mutable referent is that the compiler will check that:

• no other threads are borrowing the same referent mutably
• and the parent thread, for the lifetime of the borrows in the child threads, also doesn't mutate the referent

This last point is going to be confusing. Because the referent is declared mutable, but you can't mutate it while the other immutable references are still alive.

Am I missing some other way to take an immutable reference to a mutable referent? Could the proposal be updated to include how this can be done?

[Brian-M-J]

This is why I suggested decoupling let and var from specifying whether a value is immutable or not:

let and var can be made completely orthogonal to mutability (and its lack thereof) to simplify the language and make it so that there is one way (immutable references) to assign an immutable value to a variable. Maybe let and var can be used to indicate non-reassignable and reassignable variables and nothing more.

If my idea is accepted, we would have 4 ways of declaring a variable:

1. reassignable variable, mutable reference

var a = mut [1, 2, 3]

2. reassignable variable, immutable reference

var a = ref [1, 2, 3]

3. non-reassignable variable, mutable reference

let a = mut [1, 2, 3]

4. non-reassignable variable, immutable reference

let a = ref [1, 2, 3]

(Don't pay much attention to the ref/mut syntax. I don't have any strong opinions about those and I'm not suggesting that that should be the final syntax for mutable and immutable references.)

So the only thing that would decide if a value is immutable or mutable would be on the right hand side of the assignment operator. This would simplify the language and make the programmer's intent clear:

• There would be only one way to specify an immutable value/reference
• Keeping let to mean "non-reassignable variable" means you don't have to hunt around the scope of a variable to see if it still points to the same object.

[lattner]

Hi @rarebreed, sorry for the delay. The design for references is still getting designed, so I can't give you a specific answer to how the syntax will work in full. That said, your question seems pretty independent of this proposal: even if we have both let and var, we'll want to be able to form an immutable reference to a mutable var: there are lots of reasons for something to be a var in current mojo that are orthogonal to what you'd want the reference to be.

[Eprahim-taha]

#1506 (comment)

You could remove the keyword ( var ) Why don't we simplify things?

var a: String = "Hello Mojo 🔥" ❌

a: String = "Hello Mojo 🔥" ✅. # Here Mojo Compiler 🔥 will recognize the type of the
variable at compile time

If you write the variable type as we explained in the previous example, the variable type will be recognized at compile time. If you do not write the variable type, the variable type will be recognized at run time For example

a = "Hello Mojo 🔥" ✅ # here Mojo Compiler 🔥 will recognize the type of the variable
at runtime

[Brian-M-J]

From the proposal:

Unlike traditional Python behavior, var introduces an explicitly declared and lexically scoped value: we need some introducer and do want scoped declarations.

Python has weird variable scoping rules (eg: being able to use a variable after a loop even though it was declared inside the loop). For example, the following Python code is perfectly valid:

for i in range (10):
    a = i + 1
print(a)  # Prints 10

My guess is the Modular team needs stricter scope rules for systems programming stuff (idk what exactly, but my guess is to catch typos and prevent programmers from declaring a variable they didn't intend to) which is why they want to keep var.

[Eprahim-taha]

In my opinion the decision to remove let It is an ill-advised decision and I would never encourage it. I have a very strong background in rust programming language And I know the importance let

[oskgo]

@Brian-M-J A language with well optimized compilation wants stricter scope rules to avoid use of uninitialized variables. We know that a will always be initialized before the loop exists, but only because we know the semantics of range(10). If the iterator can be arbitrary it might not execute even a single loop iteration.

There are a couple of ways to deal with this. You could declare it UB to access uninitialized variables or use some random garbage value, which are both giant footguns. You could have language-wide nullability to track initialization, which slows down execution and increases memory usage. Finally, you can require a static guarantee that a variable is uninitialized before it is accessed, which prevents things like the loop you showed. With the final approach you can still opt into nullability or potential UB, but the default is more performant than the second approach and safer than the first. The downside is that you have to be explicit about wanting more flexibility when you want it.

[CosynPa]

If mutation and reassignment are two things, does it mean we can have an immutable reference that can be reassigned?

struct A:
    var x: Int
    var y: Int
    
    fn __init__(inout self):
        self.x = 0
        self.y = 0
    
fn f(borrowed a: A):
    a.x = 1  # Error
    a = A()  # Should be OK?

[lattner]

No, these are invalid in both current-Mojo and Mojo-without-let.

[Brian-M-J]

No, these are invalid in both current-Mojo and Mojo-without-let.

If that's how it is, then the case for my suggestion is made even stronger:

let and var can be made completely orthogonal to mutability (and its lack thereof) to simplify the language and make it so that there is one way (immutable references) to assign an immutable value to a variable. Maybe let and var can be used to indicate non-reassignable and reassignable variables and nothing more.

It would be much easier to explain why the code above is invalid if non-reassignability wasn't restricted to only certain parts of the language but was able to be used anywhere.

P.S. I'm not particularly attached to the let keyword itself, just to the ability to declare non-reassignable variables. If let is not clear enough, it can be replaced with fix as suggested by another Mojician or maybe pin.

[rarebreed]

If mutation and reassignment are two things, does it mean we can have an immutable reference that can be reassigned?

struct A:
    var x: Int
    var y: Int
    
    fn __init__(inout self):
        self.x = 0
        self.y = 0
    
fn f(borrowed a: A):
    a.x = 1  # Error
    a = A()  # Should be OK?

This is why the more I think about it, I feel like reassignment of local variables and immutable references is not going to be easier to teach for both python programmers and system programmers.

Now you have several confusing aspects:

• What's the difference between reassignment at the value level, vs immutability when borrowed?
• Transferring ownership immutably should be ok from a mutable local variable, but that's kind of confusing too
• How can I even borrow a value immutably, when the local itself (the referent) can be mutable?
• Is reassignment the same as shadowing? (do we "forget" the symbol in the namespace and drop the old value?)

So the more I think about this, I think it's not just a "nice to have"

[rarebreed]

Hi @rarebreed, sorry for the delay. The design for references is still getting designed, so I can't give you a specific answer to how the syntax will work in full. That said, your question seems pretty independent of this proposal: even if we have both let and var, we'll want to be able to form an immutable reference to a mutable var: there are lots of reasons for something to be a var in current mojo that are orthogonal to what you'd want the reference to be.

No worries at all for the delay, I am sure all of you at Modular are super busy :)

I understand var has some orthogonal concerns like allowing lexical scoping. Anf yeah, I could imagine a way for the compiler to create an immutable reference to a mutable var, but I was trying to think of the ramifications (eg, how it would play out with multiple threads,). My bigger concern at the moment is the teaching aspect of this and explaining immutability only at the reference and owned argument level.

Right now, I still don't have a good picture how removing let will play out with references, ownership, and (im)mutability especially with regard to the duality of mojo needing to be a superset of python.

[oskgo]

Regardless of whether it's a good idea to have immutable bindings in general it's worth noting that adding let back in can be done backwards compatibly, while removing it cannot.

At such an early stage it's probably better to avoid features like let that increase complexity and don't clearly and fundamentally change what you can do with the language. If it is missed it can be added in later, when the rest of the language has crystalized more and we better understand the practical consequences of not having it in Mojo.

[MilosheskiA]

In my opinion let should stay in Mojo. Altho my primary language is Python, i do love Swift, and from time to time use Rust when i need the performance that Python can’t achieve (hopping to switch to Mojo for this :) ). My reasons are the following:

1. Although Mojo does support alias, having the option to declare a constants value in a struct or a function is extremely valuable in my opinion. Having something like:

struct Meters_convertor:
let cm: Int = 1000
Would be very valuable I believe.

2. Since Mojo does have an Optional type, using the “if let” would be awesome to have. Python has something similar with the walrus operator “:=“, not quite the same but similar enough so that the concept is not that foreign.

3. Although Python indeed does not have constants per say, the convention still exists. Defining a “variable” all uppercase is practically the same, but without the benefit that Mojo offers of having the immutability. As an example for a use case of this would be; hyper parameters, or a URL/I, file path, and so on.

class Example:
LR = 0.0001
BATCH_SIZE = 32

I realize that this may be done with using alias, but having this being explicit feels more natural, granular if you will.

4. Although Mojo is intended to be a superset of Python, it also states that you could go much lower level if you need (want) to. Adding things like structs, ownership and generics dose bring it closer (in syntax) to Rust and Swift (and I don’t think that’s a bad thing at all). So people coming from those languages would already be familiar with this concept, and IMO having something familiar would help spread the Mojo around :) .

[Brian-M-J]

I realize that this may be done with using alias

That is, unless the value of the constant depends on a runtime value; let fulfills a role that neither alias nor var do.

Although Python indeed does not have constants per say

It's really not accurate to say that Python has no concept of constants. As I mentioned here, it has 3 ways of declaring non-reassignable variables. When you combine that with value semantics, which Mojo seems to lean heavily into (and which is present in Python's value types like int, str, tuple, frozenset, range, bytes and also the types in the datetime and pathlib modules, decimal.Decimal, fractions.Fraction, uuid.UUID etc.; basically any hashable type), you get constants.

So I don't get arguments like:

The notion of immutable variables is entirely new to Python programmers

[Making mutability more verbose] cuts very hard against a lot of the design center of Python, which doesn’t even have this concept at all

[keeping let is] not worth it on balance with the cons and complexity it introduces for programmers and the wedge it produces with existing python programmers

On one hand, while python doesn't have a concept of a const or immutable local named variable [...] python lacking the concept of immutability

It's accurate to say that Python does not have a notion of compile time constants (all checks happen at run time unless you're using a type checker), but I don't see how that's a limitation on Mojo which aims to provide many compile time checks and powerful compile time metaprogramming.

Also, I don't know how removing let will play out with enforcing that user defined hashable types really are immutable. A hashable type can't just arbitrarily reassign its fields. Python has runtime checks for these (NamedTuple and dataclass), but how will Mojo enforce this at compile time without let? Mojo behaving like Python would probably be the worst outcome here because it would mean that users have to pay a run time cost for this checking.

[lattner]

Thank you all for the feedback on this. At this point, we've decided that it is the right local step to remove let to simplify the language and focus on the core parts of the model. This is in part because we want to prioritize nailing down the right semantic model for lifetimes and the borrow checker (which does need immutability and mutability both of course) but also because let was added prematurely without baking it out. At this point, the 0.7 release has started the process to remove let: we no longer push code to use let instead of var. In a future release, we'll change it so let is a synonym of var, and at some point after that we'll drop let entirely.

However, if you're a fan of let in the language, have no fear: Mojo will grow up quickly early this year, these core subsystems will get more baked out, and we'll work up-stack into dynamic features. As the language matures and we get a more significant library ecosystem with usage experience, we'll be able to re-evaluate the re-introduction of let. I don't think any of us will forget about it! :-)

[gryznar]

If let will be restored, I hope, that with more obvious name xD

[melodyogonna]

Instead, const >>>

[soraros]

named immutable variables aren't a core programming concept

Says the compiler nerd using SSA pervasively in all his four lettered technology.

[CosminSontu]

@gryznar val seem to be the right choice, and alias could be comptime / const

[Sarctiann]

I know that I'm late here, also I'm not a good English speaker so this will be short.

intro

I think removing let could be bad, especially if the default behavior will create an immutable variable¹.
Also, this could be confusing between fn and def functions since a def one doesn't require a variable specifier for declaration/initialization, which, as I see, results in a context-meaning

behavior (mutable for def functions and immutable for fn functions) in another way, def functions would be no longer full Python-compatible.

I think the perfect way to build mojo, is following the Python default behavior² (at syntax meaning). With every possible compiler optimization. And then add Mojo🔥 syntax to improve it.
I understand that "decisions were made into Python" and Mojo has the opportunity to do it better, due to that, this kind of crossroads will appear more than once.

---

my thoughts

In my opinion, we definitely need an initializer specifier for immutable vars in MOJO, since we don't have such of thing in Python. On the other hand, I like let because it has 3 chars, the same var, and since Python/Mojo are languages where code-alignment counts, is not a completely trivial thing. const on the other hand ... well, not much to say only javascripters could like that keyword. I would prefer to reserve that keyword for something like global constants rather than immutable variables.

I think that a much better idea could be to infer the type of variables without let or var as mutable PythonObjects. I think that will be much more predictable and have no context meaning. And keep using let and var or any other names I really don't care a lot, always that they have the same length PLEASE! 🥲.

In Python, we have the walrus operator := for variable declarations inside condition expressions. Maybe we can leverage that syntax to find a shortcut for Mojo variable declarations.

Footnotes

1. I like immutable variables by default in other languages. But I feel this is against Python's default behavior ↩

2. At the beginning Mojo promised that the general idea was "Just Python, with an extra powerful syntax addition to access the low level ❤️. ↩

[gryznar]

As far as I understand statement from Chris Lattner, removing will be temporarily. I mean that declaring immutable variable would be reintroduced in the future, so it is not disappearing forever ;)

[Brian-M-J]

And keep using let and var or any other names I really don't care a lot, always that they have the same length PLEASE!

Big agree. I don't see any point in the Rust approach of punishing programmers for introducing mutability into their programs. I also don't want the C++ approach of making it so tedious to specify immutability that no one cares ("How many consts do you want me to add?!")

@gryznar The impression I got is that it may be added in the future. There was no guarantee at all.

[gryznar]

Yeah, there is no guarantee but Chris say to not loose the hope xD

[Brian-M-J]

Gotta stay strong lads

[melodyogonna]

It is disappearing forever unless a practical reason for its continued existence shows itself. For now the team doesn't think it's worth the complexity it introduces into the compiler.

[Moosems]

Personally, I liked the let declaration. It felt fairly simple and verbose.

[nmsmith]

I commented about my thoughts on lets removal on Discord. I'll repost it here:

I was initially opposed to the removal of let, but I've since warmed up to it.

As a language feature, let basically does nothing. It has no influence on the runtime behaviour of a program. It's essentially just a #comment on steroids. (Albeit, a useful comment.)

It's weird to have a language feature that does nothing. Furthermore, it's awkward to have to teach new Mojo users about this nothingness, right at the beginning of their learning journey. So I can sympathize with lets removal, even if I have historically been a fan of immutability.

As a "fancy comment", let has two main utilities:

• It allows a programmer to signal that they don't intend for a variable's value to change.
• It allows the compiler to alert the programmer that the program is not consistent with this intention.

There's no particular reason why this intention needs to manifest as a keyword. I suspect 90% of the benefit can be achieved just by using an IDE that colors variables differently depending on whether they are mutated at some point. If you accidentally mutate a variable, its color will change. Most of the time you'll notice this, and stop and think whether you've make a mistake. (Assuming you read your code before committing it!)

[nmsmith]

I don't see how that's a bad thing. A common rule for commenting is, "Don't express in comments what can be expressed in code."

It's not a very helpful comment though. All you can infer from a let is: "at the time this code was written, there was no need to mutate this variable." If you enter a new codebase and there are a bunch of lets everywhere, and you decide that you want/need to mutate one of those variables, I'd expect that the vast majority of the time, it would be safe to do that. Just change it to a var and away-you-go.

In short: I would wager that the vast majority of lets aren't upholding any important invariants. They aren't "warnings" to future maintainers.

[melodyogonna]

Indeed. I've never written a code where I had a let that can't be changed because it would introduce a bug. Correctness is maintained by an automated test.

Every language has the convention of declaring unchangeable constants with all-uppercase naming usually at the top of a file, this does not require any special language construct. I believe the problem let solves is superficial.

[soraros]

I've never written a code where I had a let that can't be changed because it would introduce a bug.

Counter point: consider all the type annotation in Typescript and Python that can be safely stripped, yet still invaluable.

Correctness is maintained by an automated test.

"Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence." Nothing beats having the compiler prove to you the lack of certain misbehaviour (both in a mathematical and empirical sense).

Every language has the convention of declaring unchangeable constants with all-uppercase naming usually at the top of a file, this does not require any special language construct.

This use case is mostly covered by alias, which is an entirely different thing. The statement "every language has this convention" is just illogical, I hope you meant it more hyperbolically. Many do, but that's irrelevant. You can change the meaning of integer literals at runtime in Python right within the REPL; that's what the overly permissive "key under the mat" style "enforcement" gives you, it's horrible.

I believe the problem let solves is superficial.

I think this view is largely shaped by the languages you had experience with (to be fair, whose view isn't). One can live without having mutability or even variable at all. Having immutable binding not only enhances local reasoning (main point of value semantics), but also enables a more functional style in Mojo. Example that better support for FP is not merely an aesthetics concern, but essential to Mojo's main goal, ML: all models in JAX are written in functional style.

[Moosems]

@Brian-M-J While that explains a lot of things nothing prevents the Mojo team from making that UB or having that return a compiler error.

[CosminSontu]

let keyword does(did) something: it makes the compiler keep you accountable for the fact that you said you won't change that value.

This is pretty important!

Otherwise you might say, unit tests don't do anything. (Indeed, they just keep you accountable for the behaviour they assert)
If you change your design, of course you will change your unit tests(like you would change let into var).
Does that mean they are not useful ?

PS: I think var goes well with val not let... In case it will get back :)
PS: I think "making mojo more like Python" mantra is unhealty and might compromise mojo if bad parts are not left out.

[RtyLiu]

The only value of let is to prevent developer from changing a variable. Ha ha, why is variable then :). What is next, init time property setters like in C# or billion of setters and getters like in Java. You have alias-es, immutable references, immutable attributes. There are a lot of features to be done (bugs cleaning too). Make first them, then working superset of Python and than add what you want, but Mojo should never loose one feature - Speed.

[lattner]

Hi all, it has come time to close this proposal. For the record, Mojo still has support for strong immutability (e.g. borrowed arguments, immutable Reference), it only removed local immutability. We've discussed this, agreed on it, and executed towards it.

Mojo 24.1 removed support for let from the compiler IR (but it still parses let for migration), subsequent releases will remove the let keyword entirely.

[hello-sergei]

I consider removing "let" from Mojo a good pragmatic decision at this stage. Better get the basics right first, and extend the language in a principled way later.

For instance, we can start from observing that we may have two boolean attributes for a "name bound to a value" concept: mutable type vs immutable type (let's call them here Wildcard vs Typed), and mutable value vs immutable value (Variable vs Constant). This generates four kinds of this concept:

Wildcard Variable, Typed Variable, Wildcard Constant, Typed Constant.

Another concept we could use is that of default context. For instance, default context for a "name bound to a value" in Python is Wildcard Variable. Default context for Swift is Typed, further concretized by "var" (Typed Variable) and "let" (Typed Constant).

Wildcard Constant, while appearing perplexingly exotic, could be semantically beneficial for principled casting, as a Wildcard Constant with value "1", for instance, may be used for assignment to a Typed Variable with type Int, Float, Complex, String etc.

For generality, it would be beneficial to allow specifying one of the four kinds of "name bound to a value" per each occurrence, whereas "def" and "fn" would, among other things, indicate the default contexts. The "def", Pythonic context, would stay as it is now for the foreseeable future. The "fn" may be extended with the explicit declarations of the four kinds.

If we derive "wild" from "wildcard", the syntax could be even made amusing/invigorating. I'd love to be able to write "wild var" and perhaps "wild const" :) I think it would be easy to explain to students that all the names bound to values in classic Python are simply Wild Variables.