6 ms·

It's common to hear people refer to &T and &mut T not as "mutable" or "immutable" but "shared" versus "unique". What probably muddles this is that the `mut` key

by saghm 5y ago

It's common to hear people refer to &T and &mut T not as "mutable" or "immutable" but "shared" versus "unique". What probably muddles this is that the `mut` keyword _also_ is used for declaring things mutable or immutable, just at the binding level rather than the type level. These are related due to the fact that you can't take a `&mut` reference to a binding that isn't declared as `mut`, which probably also muddles the water a bit.

tptacek 5y ago
&mut is kind of gross syntactically anyways; another thing that would have clarified this would have been to rename & to &shared, which has symmetry.
- ReactiveJelly 5y ago
  Nah, I like having immutable syntax be shorter. It makes idiomatic code shorter than code that does a lot of mutating
  - saghm 5y ago
    Agreed! I also like that declaring a mutable binding is extra code beyond a regular binding rather than something the same (or shorter). At least for me, making things immutable by default and then only relaxing it when necessary leads to code that tends to be less buggy, and I suspect this might be true for others as well.
- the_duke 5y ago
  Rust is already an ugly language. Having &shared plastered all over your code base would be ... suboptimal. Not everything in a language needs to be 100% self descriptive. I think the designers arrived at a good tradeoff.
- Quekid5 5y ago
  That's kind of point, tho... I feels gross because it should?
nyanpasu64 5y ago
There's one other oddity, where `let x: &mut T` allows mutating the target, while `let x: Box<T>` or `T` doesn't. fn box_immut(x: Box<i32>) { // illegal *x += 1; } fn ref_immut(x: &mut i32) { // legal *x += 1; } IIRC under the current current Rust-to-LLVM compilation rules, &mut T is noalias (because it's exclusive), and &T is noalias or readonly or something (because all other &T are immutable) unless T contains an UnsafeCell. It actually took many years to get &mut T to be noalias without exposing LLVM bugs resulting in miscompiled Rust (which went undiscovered because Rust is the first LLVM language to use noalias so heavily). And noalias and pointer aliasing is a huge mess, with crates like owning_ref and Tokio's intrusive linked lists and Pin<Box<T>> being unsound under the proposed Stacked Borrows rules. And I just found a LLVM codegen soundness issue: https://github.com/rust-lang/rust/issues/63787 https://github.com/rust-lang/rust/issues/63787.
Matumio 5y ago
This was my biggest misconception when learning Rust. I was thinking "&mut" can modify data, so "&" cannot. Wrong. The "mut" keyword is not the opposite of "const" from C++. It's declaring that you have exclusive (unique) ownership at this moment.
- afiori 5y ago
  to be pedantic &mut is still a borrow not ownership, as another simplification the difference is that &mut can modify a value but must keep the borrowed value in a valid state, while full ownership can destroy a value

by saghm 5y ago

tptacek 5y ago

&mut is kind of gross syntactically anyways; another thing that would have clarified this would have been to rename & to &shared, which has symmetry.

ReactiveJelly 5y ago
Nah, I like having immutable syntax be shorter. It makes idiomatic code shorter than code that does a lot of mutating
- saghm 5y ago
  Agreed! I also like that declaring a mutable binding is extra code beyond a regular binding rather than something the same (or shorter). At least for me, making things immutable by default and then only relaxing it when necessary leads to code that tends to be less buggy, and I suspect this might be true for others as well.
the_duke 5y ago
Rust is already an ugly language. Having &shared plastered all over your code base would be ... suboptimal. Not everything in a language needs to be 100% self descriptive. I think the designers arrived at a good tradeoff.
Quekid5 5y ago
That's kind of point, tho... I feels gross because it should?

nyanpasu64 5y ago

There's one other oddity, where `let x: &mut T` allows mutating the target, while `let x: Box<T>` or `T` doesn't. fn box_immut(x: Box<i32>) { // illegal *x += 1; } fn ref_immut(x: &mut i32) { // legal *x += 1; } IIRC under the current current Rust-to-LLVM compilation rules, &mut T is noalias (because it's exclusive), and &T is noalias or readonly or something (because all other &T are immutable) unless T contains an UnsafeCell. It actually took many years to get &mut T to be noalias without exposing LLVM bugs resulting in miscompiled Rust (which went undiscovered because Rust is the first LLVM language to use noalias so heavily). And noalias and pointer aliasing is a huge mess, with crates like owning_ref and Tokio's intrusive linked lists and Pin<Box<T>> being unsound under the proposed Stacked Borrows rules. And I just found a LLVM codegen soundness issue: https://github.com/rust-lang/rust/issues/63787 https://github.com/rust-lang/rust/issues/63787.

Matumio 5y ago

This was my biggest misconception when learning Rust. I was thinking "&mut" can modify data, so "&" cannot. Wrong. The "mut" keyword is not the opposite of "const" from C++. It's declaring that you have exclusive (unique) ownership at this moment.

afiori 5y ago
to be pedantic &mut is still a borrow not ownership, as another simplification the difference is that &mut can modify a value but must keep the borrowed value in a valid state, while full ownership can destroy a value