Why was &mut x chosen over mut &x for mutable references?
I find the syntax &mut x for mutable references less readable than a hypothetical mut &x. With &x, the & is directly before the variable name, clearly indicating a reference. Adding mut to form mut &x would preserve this structure, keeping & next to the variable for better visual consistency and easier scanning. However, &mut x shifts & left and introduces a space, making it harder to quickly recognize the reference.
Were there historical discussions or design decisions (e.g., during pre-1.0 development or "mutpocalypse") that considered mut &x as an alternative? If not, why was &mut x preferred, despite its impact on readability?
I'd say this is actually an improvement on readability, if you accept the point of view that shared and exclusive/mutable references are two distinct things and not two variants of the same thing. You want to know at a glance whether the borrow you're working with is exclusive or not, and having &T in this case would somewhat obscure the mut part.
3 Likes
If I had to guess, it's because the mut in &mut T is describing what can be done to the T and not to the reference.
Whatever design went into it isn't reference specific and predates &mut _.
You would have four kinds of Rust pointers:
@MT --- pointers to task-local, boxed data
~MT --- pointers to unique data
&MT --- safe references
*MT --- unsafe, C-like pointers
Here the M refers to a mutability qualifier (default, mut, or const) and T refers to a type.
Perhaps this is closer to the origin. (It's clear they already had qualifiers by then too, though.)
2 Likes