Provide structural pinning guarantees for slices, vecs, arrays

[yoshuawuyts]

Link to Zulip Discussion.

Right now Vec provides no guarantees wrt structural pinning, meaning if we have a Vec of futures and we pin project through it, it works fine today - but we're not guaranteed it will continue to work fine tomorrow. For example, futures::join_all! notes internally that:

Safety: std could make this unsound if it were to decide Pin's invariants aren't required to transmit through slices. Otherwise this has the same safety as a normal field pin projection.

Those are pretty shaky grounds to build on, and it'd be better if we could actually guarantee that this will continue to work fine in the future. Especially as the Async WG is looking to fold facilities akin to join_all! into the stdlib. I'm not sure what exactly we'd need to document in order to make these guarantees, hence this issue.

---

Tagging in: @rust-lang/wg-async, @rust-lang/wg-unsafe-code-guidelines, and also @RalfJung specifically since they've been working on the intersection of soundness and pinning recently.

[RalfJung]

Arrays are a no-brainer I think.

Slices are basically references which are always Unpin, right? So it can't be structural?

For Vec, again since it is a ptr indirection I think the default policy would be to say that it is not structural. (That doesn't mean using it as if it were structural is unsound. It just means that when you get a Pin<&mut Vec<T>> from unknown code, you cannot assume that the elements are pinned.)

[RalfJung]

Slices are basically references which are always Unpin, right? So it can't be structural?

Oh I see, this is about Pin<&mut [T]>, not Pin<&mut &mut [T]>. It's about whether the type [T] is structural.

Yeah I think that's exactly like arrays, and we should say it is structural.

[CAD97]

100% agree that we should say that Pin<&mut [T]> requires T to be structurally pinned. If we already say this is the case for [T; N], this is already true by proxy in that you can coerce Pin<&mut [T; N]> into Pin<&mut [T]>.

Pin<&mut Vec<T>> must match the standard rules for Pin, in that because Vec<T>: Unpin, Pin<&mut Vec<T>> is equivalent to just &mut Vec<T>.

Pin<Vec<T>> pins the [T]. This is not a type which is valid to construct at the moment. Vec is also extra annoying because it's still a mostly open question as to whether it should be considered unique the same way &mut [T] or Box<[T]> are. Imho Pin<Vec<T>> should not be used until/unless std provides a way to construct and interact with Pin<Vec<T>>, and that shouldn't happen until we're committed on whether Vec gets LLVM-noalias. Instead, use Pin<Box<[T]>>.

[EqualMa]

I think this issue is not about Unpin or Pin<Vec<T>>. It's about whether it is safe to pin project:

• Pin<&mut [T; N]> to [Pin<&mut T>; N]
• Pin<&mut [T]> and Pin<&mut Vec<T>> to
  Vec<Pin<&mut T>> or impl Iterator<Item = Pin<&mut T>>

I am even not sure if std guarantees pin-projection of tuples (whether it is safe to pin project Pin<&mut (T1, T2, ..., TN)> to (Pin<&mut T1>, Pin<&mut T2>, ..., Pin<&mut TN>))

Hope std provides methods of these pin-projections.