Add `{UniqueRc, UniqueArc}::into_pin`

[ibraheemdev]

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.

[programmerjake]

I don't think that's sound assuming you can convert Pin<UniqueArc<T>> to Pin<Arc<T>> (which seems entirely reasonable) because UniqueArc<T> lets you create Weak<T>, so you can break the pinning guarantee:

fn move_pinned(v: T, f: fn(Pin<Arc<T>>)) -> T {
    let unique_arc = UniqueArc::new(v);
    let weak = UniqueArc::downgrade(&unique_arc);
    let pinned_arc: Pin<Arc<T>> = UniqueArc::into_pin(unique_arc).into();
    f(pinned_arc.clone());
    let arc = weak.upgrade().unwrap();
    drop(pinned_arc);
    Arc::into_inner(arc).unwrap()
}

[ibraheemdev]

@programmerjake the proposed API creates a Pin<Arc<T>> directly. You're correct though, it would have to panic if any weak references were created (or alternatively, the API could be fallible). Note having this API on UniqueArc means there are no potential race conditions (and no need for locking the weak count, for example).