&mut is really a Mutant Reference! 😁

As a newbie reading rust lang book, at about 7th time, after the book says '&mut is a mutable reference', and after about an hour reading all the other newbies before me, stumbling and complaining about the same fact, that rust lang is silently overriding 40 years of 'mutable reference' semantics like this, and that rust '&mut' is really none of these:

C/C++
const T* const a; // can't mutate either
const T* a;       // can't mutate what is pointed to
T* const a;       // can't mutate pointer
T* a;             // can mutate both

I propose a better name: &mut is really a Mutant Reference! :grin:

And a little footnote in the rust lang book relevant chapter:
"A Mutant Reference really means exclusive access, blah, blah, blah".

The name comes with real benefits:

  • it is fun, and will create lots of great memes
  • any newbie will instantly recognized that 'mutant' is not 'mutable'
  • it will save zillions of newbie man-hours in the next 100 years or rust

I hope that the "Rust People" will consider this brilliant idea very seriously. :grin:

1 Like

Well, in Rust bindings and references are immutable by default, so here's a rough equivalent:

struct T;

fn main() {
    let t1: &T = &T; // Can't mutate either.
    let mut t2: &T = &T; // Can't mutate what is referenced.
    let t3: &mut T = &mut T; // Can't mutate binding, but what is referenced.
    let mut t4: &mut T = &mut T; // Can mutate both.
}

However, making the binding immutable does not give the same guarantees as a C++ const does, because of Rust's shadowing.

3 Likes

No. Rust does not "silently override" anything. Rust deliberately "fixes" C/C++ semantics to avoid footguns present in those languages (in the case of mutability, changing some value though pointer by mistake).

Now about your proposed name change. I understand that you wrote your suggestion in jest. However I feel obliged to explain why it is terrible idea.

  • It is even worse at self-description than "mutable reference".
  • It won't save "newbies" anything, however it would cause unimaginable churn in the community, by changing something this fundamental after over a decade past language release.
  • It goes gains current effort in the ecosystem/community to switch from "immutable/mutable" names of references (because thanks to interior mutability you can sometimes mutate though "immutable" reference), to "shared/exclusive" references, which better describe nature of data aliasing, which is more fundamental property.

So we shall replace all &mut with &excl then. I cannot imagine that this may cause any churn. :smiley: SCNR

3 Likes

There were actually attempts to call them &uniq back in pre-1.0, if I'm not mistaken.