5 ms·

> falling apart as soon as you touch things like atomics, RefCell or Mutex. Does it really fall apart? None of these constructs change the fact that if a &mut

by est31 6y ago

> falling apart as soon as you touch things like atomics, RefCell or Mutex. Does it really fall apart? None of these constructs change the fact that if a &mut T is available, you can call functions on that type that take &mut self. The only thing that breaks is the assumption that non-presence of mut implies that there is no way to call those &mut self functions. If you change it to "non-prsence of mut implies that you need extra constructs like atomics, RefCell or Mutexes in order to get mutable access" it works out again.

chrismorgan 6y ago
The mental model of & being immutable and &mut being mutable, that’s what falls apart. Here are types that are taking &, and yet are mutating themselves. This becomes a huge deal when people think that they have an immutable data structure just because they have an & reference to it. Someone will inevitably stash a mutex or similar in there because they just need to be able to mutate it this once… I mean these three times… I mean all the time. Oh, you wanted this immutable data structure so you could diff it for your VDOM or incremental calculations or whatever? Heh, guess you’ll have to find some other way or structure things so that mutations can be propagated through the object tree or something. And you’ll keep on having cache issues from time to time when people forget to jump through the right hoops. Sorry about that. So yeah, the mental model of &/&mut references being about mutability is just completely and harmfully wrong. Rust does not have a way of guaranteeing immutability.
- est31 6y ago
  > The mental model of & being immutable and &mut being mutable, that’s what falls apart. Here are types that are taking &, and yet are mutating themselves. &mut still implies mutability, and even the constructs like Mutex or RefCell still expose their mutability support via &mut references. Only atomics don't (they don't provide any &mut access). Note that you don't add const like in C/C++, you add &mut. As for the VDOM caching thing, you have a point. But even if Rust had &uniq and &shared pointers, the challenge would be the same. Users might still use constructs like RefCell.
  - chrismorgan 6y ago
    Mutex::lock() takes &self. RefCell::borrow_mut() takes &self. Those (and try_ variants) are the main ways people will use those types to gain access to their interior mutability. Sure, both do have get_mut() which takes &mut self (though these came after 1.0), but that’s seldom how you’ll actually access it. > But even if Rust had &uniq and &shared pointers, the challenge would be the same. Remember again that the mutpocalypse wasn’t ever about changing the semantics, just about fixing incorrect labelling. I’m not saying the challenges would be different, just that &mut is false advertising, giving people the impression that & means an immutable reference, when it just doesn’t. &/&mut misleads people into thinking they can have immutable data structures, but you’d actually need an OIBIT (like Send) to achieve that.
    - est31 6y ago
      > Mutex::lock() takes &self. RefCell::borrow_mut() takes &self. Those (and try_ variants) are the main ways people will use those types to gain access to their interior mutability. Yeah they take &self, but that wasn't my point. My point was what they expose, which is MutexGuard in the case of Mutex, and if you want to modify the interior, you'll likely use the DerefMut impl which returns a &mut T. Same goes for RefCell::borrow_mut(). My point was that you don't mutate a &self reference directly in these instances, but turn a &self reference into a &mut self reference and then mutate. Again, atomics are an exception. > just that &mut is false advertising it is not false advertising, it implies mutable access. Had Rust been mut by default and had &T been &const T instead, I would agree with the false advertisement point. But thankfully it's non-mut by default. Anyways, even if &mut were false advertising, and it were a bump in the learning curve, note that &uniq is such a bump too, because you have no idea what it says or implies initially. &mut makes it clear that if you want to mutate, you'll likely need a &mut somewher. But &uniq does not make this obvious, so you are required to learn something early on in Rust's comprehension, while &mut requires you to learn something later on. Generally, Rust has been criticized for having a steep learning curve at the start. In general I think it's worth it to learn Rust, but this wouldn't make it any better but worse.
      - 5y ago

by est31 6y ago

chrismorgan 6y ago

The mental model of & being immutable and &mut being mutable, that’s what falls apart. Here are types that are taking &, and yet are mutating themselves. This becomes a huge deal when people think that they have an immutable data structure just because they have an & reference to it. Someone will inevitably stash a mutex or similar in there because they just need to be able to mutate it this once… I mean these three times… I mean all the time. Oh, you wanted this immutable data structure so you could diff it for your VDOM or incremental calculations or whatever? Heh, guess you’ll have to find some other way or structure things so that mutations can be propagated through the object tree or something. And you’ll keep on having cache issues from time to time when people forget to jump through the right hoops. Sorry about that. So yeah, the mental model of &/&mut references being about mutability is just completely and harmfully wrong. Rust does not have a way of guaranteeing immutability.

est31 6y ago
> The mental model of & being immutable and &mut being mutable, that’s what falls apart. Here are types that are taking &, and yet are mutating themselves. &mut still implies mutability, and even the constructs like Mutex or RefCell still expose their mutability support via &mut references. Only atomics don't (they don't provide any &mut access). Note that you don't add const like in C/C++, you add &mut. As for the VDOM caching thing, you have a point. But even if Rust had &uniq and &shared pointers, the challenge would be the same. Users might still use constructs like RefCell.
- chrismorgan 6y ago
  Mutex::lock() takes &self. RefCell::borrow_mut() takes &self. Those (and try_ variants) are the main ways people will use those types to gain access to their interior mutability. Sure, both do have get_mut() which takes &mut self (though these came after 1.0), but that’s seldom how you’ll actually access it. > But even if Rust had &uniq and &shared pointers, the challenge would be the same. Remember again that the mutpocalypse wasn’t ever about changing the semantics, just about fixing incorrect labelling. I’m not saying the challenges would be different, just that &mut is false advertising, giving people the impression that & means an immutable reference, when it just doesn’t. &/&mut misleads people into thinking they can have immutable data structures, but you’d actually need an OIBIT (like Send) to achieve that.
  - est31 6y ago
    > Mutex::lock() takes &self. RefCell::borrow_mut() takes &self. Those (and try_ variants) are the main ways people will use those types to gain access to their interior mutability. Yeah they take &self, but that wasn't my point. My point was what they expose, which is MutexGuard in the case of Mutex, and if you want to modify the interior, you'll likely use the DerefMut impl which returns a &mut T. Same goes for RefCell::borrow_mut(). My point was that you don't mutate a &self reference directly in these instances, but turn a &self reference into a &mut self reference and then mutate. Again, atomics are an exception. > just that &mut is false advertising it is not false advertising, it implies mutable access. Had Rust been mut by default and had &T been &const T instead, I would agree with the false advertisement point. But thankfully it's non-mut by default. Anyways, even if &mut were false advertising, and it were a bump in the learning curve, note that &uniq is such a bump too, because you have no idea what it says or implies initially. &mut makes it clear that if you want to mutate, you'll likely need a &mut somewher. But &uniq does not make this obvious, so you are required to learn something early on in Rust's comprehension, while &mut requires you to learn something later on. Generally, Rust has been criticized for having a steep learning curve at the start. In general I think it's worth it to learn Rust, but this wouldn't make it any better but worse.
    - 5y ago