Stream: t-lang

Topic: `Pin` found to be unsound

RalfJ (Nov 18 2019 at 19:48, on Zulip):

Cc @boats @Taylor Cramer @centril

centril (Nov 19 2019 at 08:10, on Zulip):

I saw; haven't processed yet

centril (Nov 19 2019 at 08:11, on Zulip):

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

RalfJ (Nov 19 2019 at 10:20, on Zulip):

IRLO is official though?

RalfJ (Nov 19 2019 at 10:20, on Zulip):

I agree about having an issue for tracking, but discourse is just the better medium for discussion that GH^^

RalfJ (Nov 19 2019 at 10:22, on Zulip):

issue filed:

RalfJ (Nov 19 2019 at 10:23, on Zulip):

Feel free to add more labels to that issue, I am not sure what makes sense. P-high? I-nominate?

centril (Nov 19 2019 at 11:33, on Zulip):

ok this is good for now; added some labels

simulacrum (Nov 22 2019 at 02:24, on Zulip):

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

simulacrum (Nov 22 2019 at 02:25, on Zulip):

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

boats (Dec 06 2019 at 14:05, on Zulip):

@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.

simulacrum (Dec 06 2019 at 14:38, on Zulip):

(I thought so, but wanted to point it out in case it was relevant. Thanks for taking a look!)

Last update: May 27 2020 at 22:30UTC