Have you read the appropriate blog post? The trouble with mut in Rust lies with the fact that let mut and &mut are quite different yet people like to conflate these.
But note the difference:
let mut x: i32;
vs
let x: &mut i32;
Note that we are not writing:
let x: mut i32;
which would correspond to how C++ works (and probably would work with your mental model).
But Rust is different. There was an attempt to change it (by removing mut from let, mind you, not by moving mut to the type), but by now it's kinda too late, trying to replace &mut with &uniq at this point would just create more confusion.
@VorfeedCanal thank you for clarifying. I did misunderstand the scope of the discussion. My points only relate to borrow, exclusive borrow and ownership.
My subsequent argument for mut, is in its utility as a flag within a scope that helps switch mindset going from non-mutable to mutable contexts. I liken it to using the unsafe or dyn flags. It promotes good things in the long run.
The new user confusion is a worthwhile discussion.
My take on how to message the concept is that once you have ownership, anything goes. Right now it’s presented as does not endow much other than “responsible for calling drop”… or the like.
The first statement holds because a function can recast ownership to anything And recast to mut without activating the borrow checker[1]. That last point is a big deal in Rust.
What do you think about these ideas?
which limits what one can do with the memory to which it points and thus emphasizing the relative power of ownership ↩︎