`Box::take` for taking the value out of a box without deallocating it

[edwloef]

Proposal

Problem statement

There's no provided way of taking the value out of a box without also deallocating the heap memory it owns. This could be useful to either defer deallocation to some other point in time, or to deallocate on a different thread, or to reuse that allocation for another boxed value (using Box::write).

Motivating examples or use cases

In message-oriented applications it's a fairly common practice to minimize the message enum type's size by boxing very large variants (see clippy::large_enum_variant). However, this currently isn't easily usable in realtime-constrained situations. A usecase could look like this:

enum RealtimeMessage {
    VeryLarge(Box<VeryLarge>),
    ...
}

enum NonRealtimeMessage {
    Deallocate(Box<MaybeUninit<VeryLarge>>),
    ...
}

match consumer.pop() {
    RealtimeMessage::VeryLarge(very_large) => {
        let (very_large, uninit) = Box::take(very_large);
        producer.push(NonRealtimeMessage::Deallocate(uninit));
        ...
    }
    ...
}

Solution sketch

impl<T> Box<T> {
    pub fn take(boxed: Box<T>) -> (T, Box<MaybeUninit<T>>);
}

Alternatives

• don't box the value
• a Vec<T> with one item
• Box<Option<T>> and Option::take
• Box<MaybeUninit<T>> and MaybeUninit::assume_init_read
• Box<ManuallyDrop<T>> and ManuallyDrop::take

[kennytm]

Box<ManuallyDrop<T>> and ManuallyDrop::take

If the API instead is fn into_manually_drop(this: Box<T>) -> Box<ManuallyDrop<T>> you could reuse the existing ManuallyDrop::take, but the UX extremely bad because chaining is banned

let mut to_be_dropped = Box::into_manually_drop(very_large);
// SAFETY: ...
let very_large = unsafe { ManuallyDrop::take(&mut *to_be_dropped) }; 
producer.push(NonRealtimeMessage::Deallocate(to_be_dropped));

Additionally the content of taken Box<ManuallyDrop<T>> is invalid, which is a dangerous footgun for the remaining safe code which may accidentally access the content (e.g. running dbg!(&to_be_dropped)).

[scottmcm]

To quote myself discussing Box::write in rust-lang/rust#129397 (comment)

I do think this would be nice for more than just this case, though. Coupled with a Box<T> -> (T, Box<MaybeUninit<T>>) it'd give a safe way to reuse allocations, too.

[edwloef]

If the API instead is fn into_manually_drop(this: Box<T>) -> Box<ManuallyDrop<T>> you could reuse the existing ManuallyDrop::take, but the UX extremely bad because chaining is banned

let mut to_be_dropped = Box::into_manually_drop(very_large);
// SAFETY: ...
let very_large = unsafe { ManuallyDrop::take(&mut *to_be_dropped) };
producer.push(NonRealtimeMessage::Deallocate(to_be_dropped));

Additionally the content of taken Box<ManuallyDrop<T>> is invalid, which is a dangerous footgun for the remaining safe code which may accidentally access the content (e.g. running dbg!(&to_be_dropped)).

Agreed, on second thought this approach seems too inconvenient and easy to get wrong for the usecases that a Box<T> -> (T, Box<MaybeUninit<T>>) could fulfill.

[Qelxiros]

As another motivating use case, this operation is almost exactly what I wrote for Box::map in rust-lang/rust#144420.

I'm not sure take is the right name, but it seems like there are already several functions of that name with explicitly different behavior, e.g. mem::take (replace with default) and ManuallyDrop::take (duplicate and leave it to the caller to maintain soundness).

[edwloef]

I suggested take because it acts as a (type-safe) parallel to Option::take (extract the value and leave no value) for my use-case, however I'm happy to bikeshed on the name once libs-api has decided that this should exist in some form or another :)

[the8472]

We discussed this during a libs-API meeting. This is a useful mirror to Box::write that scottmcm mentioned, so we're in favor.

Please create a tracking issue and then close this ACP.

[edwloef]

Tracking issue filed at rust-lang/rust#147212 :)