Add `{UniqueRc, UniqueArc}::into_pin`

Proposal

Problem statement

Safely constructing a Pin<Rc<T>> or Pin<Arc<T>> where T: !Unpin.

Motivating examples or use cases

Box::into_pin currently provides a safe way to create a heap-allocated self-referential object.

struct SelfReferential {
    data: [u8; 64],
    slice: NonNull<[u8]>,
    _pin: PhantomPinned,
}

impl SelfReferential {
    fn new() -> Pin<Box<Self>> {
        let res = SelfReferential {
            data: [0; 64],
            slice: NonNull::from(&[]),
            _pin: PhantomPinned,
        };

        let mut boxed = Box::new(res);
        boxed.slice = NonNull::from(&boxed.data);
        Box::into_pin(boxed)
    }
}

However, there is no way of doing the same for Rc or Arc, as their Pin-related APIs are restricted by the fact that they are not unique. UniqueRc and UniqueArc should provide a way around this.

Solution sketch

impl<T: ?Sized, A: Allocator> UniqueRc<T, A> {
    pub fn into_pin(value: Self) -> Pin<Rc<T>>
    where
        A: 'static;
}

impl<T: ?Sized, A: Allocator> UniqueArc<T, A> {
    pub fn into_pin(value: Self) -> Pin<Arc<T>>
    where
        A: 'static;
}

Alternatives

Arguably, the methods should be named into_rc_pin and into_arc_pin, to be consistent with into_rc and into_arc. However, it doesn't seem at all useful to want a Pin<UniqueRc<T>>, as there's no way to go from that to a Pin<Rc<T>> without deconstructing the Pin, and a UniqueRc on its own is no more useful than a Box.

Note that along with Box::into_pin, there is also an implementation of From<Box<T, A>> for Pin<Box<T, A>>, which serves the same purpose. I'm not sure whether this should be added for UniqueRc and UniqueArc as well.

Links and related work

• Tracking issue for the unstable UniqueRc and UnqiueArc.
• The initial proposal for Box::into_pin.

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

No implementation files or tests are named. Start by reading the proposal and the linked UniqueRc/UniqueArc tracking issue, then follow the libs-api feature lifecycle discussion. Done means the API design has received the required team decision and, if approved, has a subsequent implementation PR.