5 ms·

> Mutability is easier to explain initially, but teaches an incorrect mental model that hinders a correct understanding of Rust’s approach to memory safety, fal

> Mutability is easier to explain initially, but teaches an incorrect mental model that hinders a correct understanding of Rust’s approach to memory safety, falling apart as soon as you touch things like atomics, RefCell or Mutex. Could you elaborate or link to some material / discussion regarding that? I'd be very interested in how the alternative approach you're describing would change (or make unnecessary) constructs like RefCell.

chrismorgan 5y ago
The changes I described for the mutpocalypse vision are basically all there is to it, because &mut has always been a misnomer, never about being a mutable reference as its name replies, but rather about being a unique reference, that nothing else holds a reference while you have that one. The main thing the mutpocalypse sought to achieve was to adjust Rust’s syntax to match its semantics (including to remove mutability tracking on bindings, because that wasn’t part of Rust’s necessary semantics, and wouldn’t make as much sense after the trivial syntax change). The thing I’m noting about atomics, RefCell and Mutex is how they have methods that (safely) mutate themselves, despite taking &self, a supposedly immutable reference. (I’ve modified the final sentence in my original comment to clarify this.)
- NanoCoaster 5y ago
  I see, interesting point. Thank you :)
  - chrismorgan 5y ago
    I feel like making one more note. I said that “mutable references” was a misnomer and that it’s actually about unique references, but even that’s a bit of a misnomer, because it’s not quite about uniqueness, but uniqueness of access. You can have multiple &mut borrows to the same thing, but only one of them is accessible at any given time: let mut x = 1; let y = &mut x; let z = &mut *y; *z += 1; *y += 1; assert_eq!(x, 3); z and y both point to x, but only one is accessible at any point in time. Touching y finishes the z borrow; if you swapped the increment lines, it wouldn’t compile. My memory is fuzzy (this was quite some years back), but I have a vague feeling that this lack of precision in the use of the word “unique” was a factor in some baulking at the proposed change. (“You’re trying to fix something that we admit is strictly wrong, but you’re not even making it right!”)
    - xfer 5y ago
      Would this have worked pre-NLL?
      - Thiez 5y ago
        The pre-NLL version would need some additional scopes. In some ways the current borrow-checker is a lot friendlier (there are also some things possible today that weren't before) but it was also a simpler time, where one could easily imagine the various lifetimes. Getting started with the language was harder, but I think internalizing the borrow-checker was easier, because the rules were simpler and you were forced to learn them for anything more complex than 'hello world'. let mut x = 1; { let y = &mut x; { let z = &mut *y; *z += 1; } *y += 1; } assert_eq!(x, 3);
        xfer 5y ago
        Yes, the pre-NLL version makes it clear to see why swapping the assignment lines wouldn't work. EDIT: i think some tooling showing lifetimes for borrows would be very helpful. Can mir do this? I haven't tried it.
        steveklabnik 5y ago
        > Getting started with the language was harder, but I think internalizing the borrow-checker was easier, So here's a funny thing: depending on what you mean, I don't think this is actually true. Let me explain. The shortest way of explaining lexical lifetimes vs NLL is "NLL is based on a control-flow graph, lexical lifetimes are based on lexical scope." CFGs feel more complex, and the implementation certainly is. So a lot of people position this as "NLL is harder to understand." But that assumes programmers think in the simple way. I think one of Rust's under-appreciated contributions is that programmers intuitively understand control flow graphs better than we may think, and may not intuitively understand lexical scope. Sure, by some metric, NLL may be "more complex" but practically, people only report it being easier to learn and do what they would naturally expect.
        5y ago

chrismorgan 5y ago

The changes I described for the mutpocalypse vision are basically all there is to it, because &mut has always been a misnomer, never about being a mutable reference as its name replies, but rather about being a unique reference, that nothing else holds a reference while you have that one. The main thing the mutpocalypse sought to achieve was to adjust Rust’s syntax to match its semantics (including to remove mutability tracking on bindings, because that wasn’t part of Rust’s necessary semantics, and wouldn’t make as much sense after the trivial syntax change). The thing I’m noting about atomics, RefCell and Mutex is how they have methods that (safely) mutate themselves, despite taking &self, a supposedly immutable reference. (I’ve modified the final sentence in my original comment to clarify this.)

NanoCoaster 5y ago
I see, interesting point. Thank you :)
- chrismorgan 5y ago
  I feel like making one more note. I said that “mutable references” was a misnomer and that it’s actually about unique references, but even that’s a bit of a misnomer, because it’s not quite about uniqueness, but uniqueness of access. You can have multiple &mut borrows to the same thing, but only one of them is accessible at any given time: let mut x = 1; let y = &mut x; let z = &mut *y; *z += 1; *y += 1; assert_eq!(x, 3); z and y both point to x, but only one is accessible at any point in time. Touching y finishes the z borrow; if you swapped the increment lines, it wouldn’t compile. My memory is fuzzy (this was quite some years back), but I have a vague feeling that this lack of precision in the use of the word “unique” was a factor in some baulking at the proposed change. (“You’re trying to fix something that we admit is strictly wrong, but you’re not even making it right!”)
  - xfer 5y ago
    Would this have worked pre-NLL?
    - Thiez 5y ago
      The pre-NLL version would need some additional scopes. In some ways the current borrow-checker is a lot friendlier (there are also some things possible today that weren't before) but it was also a simpler time, where one could easily imagine the various lifetimes. Getting started with the language was harder, but I think internalizing the borrow-checker was easier, because the rules were simpler and you were forced to learn them for anything more complex than 'hello world'. let mut x = 1; { let y = &mut x; { let z = &mut *y; *z += 1; } *y += 1; } assert_eq!(x, 3);
      - xfer 5y ago
        Yes, the pre-NLL version makes it clear to see why swapping the assignment lines wouldn't work. EDIT: i think some tooling showing lifetimes for borrows would be very helpful. Can mir do this? I haven't tried it.
      - steveklabnik 5y ago
        > Getting started with the language was harder, but I think internalizing the borrow-checker was easier, So here's a funny thing: depending on what you mean, I don't think this is actually true. Let me explain. The shortest way of explaining lexical lifetimes vs NLL is "NLL is based on a control-flow graph, lexical lifetimes are based on lexical scope." CFGs feel more complex, and the implementation certainly is. So a lot of people position this as "NLL is harder to understand." But that assumes programmers think in the simple way. I think one of Rust's under-appreciated contributions is that programmers intuitively understand control flow graphs better than we may think, and may not intuitively understand lexical scope. Sure, by some metric, NLL may be "more complex" but practically, people only report it being easier to learn and do what they would naturally expect.
        5y ago