5 ms·
> If you can mutate through a shared reference, then there is no need to alias `&mut T`s in the first place! Unfortunately that is not true. See [1] as an exam
by celeritascelery 5y ago
> If you can mutate through a shared reference, then there is no need to alias `&mut T`s in the first place!
Unfortunately that is not true. See [1] as an example is core where mutable aliasing is needed (async generators). In this case they just added to compiler hack [2][3], but this really needs proper support in rust. Something like “AliasCell”.
[1] https://github.com/rust-lang/rust/issues/63818 https://github.com/rust-lang/rust/issues/63818
[2] https://github.com/rust-lang/rust/pull/82834 https://github.com/rust-lang/rust/pull/82834
[3] https://github.com/tokio-rs/tokio/pull/3654 https://github.com/tokio-rs/tokio/pull/3654
- Rusky 5y agoI'm familiar with this issue. But it's a self-imposed problem, not a fundamental limitation relative to C++: the "same people" decided (at different points in time, to be fair) to make the `Future` trait use `&mut Self`, and to let specific futures hold self references. This is a very different issue than the actual ability to express shared mutability in the language. With enough foresight, Rust could have "simply" used `&Self` and `UnsafeCell` for futures (and the current compiler hack with `!Unpin` is basically just replacing `&mut Self` with `&UnsafeCell<Self>` under the hood).