mojo/proposals/variable-bindings.md main # Variable Bindings in Mojo Updated June 2025. Status: Implemented in Mojo 25.4 This document provides an overview of how variable bindings work in Mojo, explaining the design points, how the pieces compose together, and some alternativ…

[image] sora: Specifying multiple bindings at once can be useful at times The only advantage I see for it is for saving characters not having to type var/ref multiple times. The question is how useful and how commonly used will it be? How many variable you will be unpacking? 2 vars saving…

You’re still thinking in Python. In Mojo this is simply a special case of irrefutable patterns, e.g. ref SomeStruct(a, b, c) = expr Not supporting it would only add unnecessary complexity. The ref/var pat = ... form always introduces fresh names. It would be highly inconsistent to forbid destructu…

[image] sora: You’re still thinking in Python. In Mojo this is simply a special case of irrefutable patterns, e.g. ref SomeStruct(a, b, c) = expr We don’t have this yet, but IIUC it’s the same question: SomeStruct(a1, ref b1) = ... # var, ref SomeStruct(ref a2, b2) = ... # ref, ref! SomeStr…

A tuple pattern is just a pattern–like a single variable name–and banning something like ref a would be absurd. I think the grammar quirk is for the following reasons: ref has higher precedence than ,, and parentheses serve both grouping and tuple construction, so: Prefix vs. comma ref a2, b2 # …

Big fan of removing the [] from all my loops. Also cursor / ai tool is going to like this a lot. I think 95% of the cases of iterating through elements for me have been read only ops. The remainder I pop ref in the loop. (edited) Some semantic weirdness maybe someone can explain to me: For …

[image] monte: The idea of making immutability the default was discussed as part of the let-proposal . I’m not suggesting bringing back let which is an immutable owned variable which will make copies. I’m suggesting to use read which an immutable ref and will prevent accidental copies e.g. whe…

[image] sora: A tuple pattern is just a pattern–like a single variable name–and banning something like ref a would be absurd. Just to be clear, I’m not suggesting removing ref a, I’m suggesting that ref and var will only be associated with a single name binding, so If you want 2 refs just typ…

[image] Yinon Burgansky: I’m suggesting that ref and var will only be associated with a single name binding, Now this is a much more reasonable request. [image] Yinon Burgansky: right now there are 2 ways: Since default is ref, there are still two ways to express the same thing. The i…

[image] jklaivins: We make them mutable by using for ref element in someelements ref is a parametric mutable reference type, which means it inherits the mutability of the type it references, for example: fn get_first_element(ref my_list: List[Int]) -> ref [my_list] Int: ref first = my_l…

Thank you for the clarification.

Variable Bindings proposal discussion

Mojo

christoph_schlumpf (Christoph Schlumpf) June 8, 2025, 5:21pm 46

I started a topic for this: The case for explicit read variable bindings

Topic		Replies	Views
The case for explicit `read` variable bindings Language Design mojo-language-design	18	618	December 23, 2025
Rename `read` argument convention and `Immut` type prefix? Language Design std-lib , mojo-language-design , mojo-proposal , mojo-1_0	83	3431	July 16, 2026
Why Variable Declaration Matters — And How Mojo Can Become Truly Python-Friendly Mojo discussion	4	240	June 17, 2026
Mojo's Ownership Model from the Point of View of a Python Developer Mojo discussion	7	198	June 11, 2026
Struct Fields – Another Place Where var Feels Out of Place Mojo	23	440	July 20, 2026

Variable Bindings proposal discussion

Related topics