Unpin references

[cramertj]

I also considered adding an impl for raw pointers as well, but that makes it easy to accidentally have unsound owning-collections that might otherwise be able to project pinned-ness (e.g. Box).

cc @RalfJung

r? @withoutboats

[withoutboats]

@bors r+

I agree

[bors]

📌 Commit a2b21e5 has been approved by withoutboats

[withoutboats]

I am fairly dubious of any data structure that would claim to safely project through raw pointers; I suppose you could create an adequate API but it seems suspicious to claim to pin project through a pointer. So I wouldn't mind the raw pointers impls either.

But I also think its fine to not have them, maybe better, just to make people implementing data structures actually think about it.

[RalfJung]

LGTM (the reference part, I don't know Waker). I also agree raw pointers shouldn't be Unpin, just like they are not Send/Sync -- to make people think about it.

The relevant property here is that from a PinMut<&mut T> we cannot get a PinMut<T>, and similar with Pin and shared references. This makes the impl Unpin safe.

Note that this would be implementable fairly easily using map_unchecked. How high do we think the risk is that someone does this?

[cramertj]

@RalfJung

Note that this would be implementable fairly easily using map_unchecked. How high do we think the risk is that someone does this?

Pretty high, unfortunately-- @aturon already did it once ;). I think this might be worth explicitly noting in the docs of map_unchecked. I also think we can prevent this by offering less footgun-y ways to project PinMut than map_unchecked-- we've started using unsafe_pinned!(fieldname -> FieldType); macros to generate projection-mapping methods in futures-rs, and that has worked well to ferret out a lot of the hard-to-analyze unsafe bits.

[RalfJung]

Might it be a good idea to have a macro in libstd that generates a map_unchecked which is guaranteed to not deref (if that's possible... it would have to avoid auto-deref)? That'd still be unsafe but less so. (I imagine unsafe_pinned! is something like that.)

Then we could add big fat warnings in the map_unchecked docs to use that macro instead, and if that does not work, triple-check if what one wants to do is safe.

[cramertj]

@RalfJung I could also imagine adding a clippy lint against a deref inside of a map_unchecked impl.

[bors]

⌛ Testing commit a2b21e5 with merge a22bcd8...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: withoutboats
Pushing a22bcd8 to master...