Cc @boats @Taylor Cramer @centril
I saw; haven't processed yet
Should also be filed as an issue on rust-lang/rust and labeled with I-unsound so that we can have the more-official discussion there
IRLO is official though?
I agree about having an issue for tracking, but discourse is just the better medium for discussion that GH^^
issue filed: https://github.com/rust-lang/rust/issues/66544
Feel free to add more labels to that issue, I am not sure what makes sense. P-high? I-nominate?
ok this is good for now; added some labels
One thing that I thought might be worth mentioning around the discussion for blanket forbidding e.g. DerefMut on
&T is a recent Embedded RFC which suggests a trait and a typical impl for
&T while the traits signature takes
&mut self -- I don't think this is really a problem in this case, but thought I'd mention it at least
In particular I haven't put in too much thought but I could imagine a design that made DerefMut for &Mutex reasonable in some sense (not sure how you'd synthesize the mutable reference, but I think you could with the right effort
@simulacrum implementing DerefMut for &Mutex doesn't work, because it needs to drop the lock in its destructor. Implementing an &mut method for an &T type presents no problems for pin and is quite different - it means exclusive access to that shared reference.
(I thought so, but wanted to point it out in case it was relevant. Thanks for taking a look!)