3 ms·

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 refer

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 6y ago
I see, interesting point. Thank you :)
- chrismorgan 6y 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 6y ago
    Would this have worked pre-NLL?
    - Thiez 6y 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 6y 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 6y 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.
        Thiez 6y ago
        Hey Steve :-) I've been following and using Rust since early 2013 (so starting around the same time you did, when I compare our contributions to the compiler) and back then I definitely did not find the lexical lifetimes hard to understand. I remember also noticing an increase in "dumb" lifetime-related questions after NLL landed, seemingly caused by a lack of understanding of how they work. Perhaps it's all just confirmation bias on my end, but I think truly understanding lifetimes was easier the way I learned it back then. That said, I have never bothered to write documentation for the Rust project, whereas few Rust contributors can claim to be in the same league as you in that area. We probably have very different perspectives.

NanoCoaster 6y ago

I see, interesting point. Thank you :)

chrismorgan 6y 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 6y ago
  Would this have worked pre-NLL?
  - Thiez 6y 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 6y 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 6y 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.
      - Thiez 6y ago
        Hey Steve :-) I've been following and using Rust since early 2013 (so starting around the same time you did, when I compare our contributions to the compiler) and back then I definitely did not find the lexical lifetimes hard to understand. I remember also noticing an increase in "dumb" lifetime-related questions after NLL landed, seemingly caused by a lack of understanding of how they work. Perhaps it's all just confirmation bias on my end, but I think truly understanding lifetimes was easier the way I learned it back then. That said, I have never bothered to write documentation for the Rust project, whereas few Rust contributors can claim to be in the same league as you in that area. We probably have very different perspectives.