Tracking Issue for Box::take

Feature gate: #![feature(box_take)]

This is a tracking issue for Box::take, which adds the ability to move the value out of a Box without consuming its allocation.

Public API

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

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

ACP: Box::take for taking the value out of a box without deallocating it libs-team#663
Implementation: implement Box::take #147227
Final comment period (FCP)¹
Stabilization PR: stabilize Box::take #160436

Unresolved Questions

~~Is take the right name? Box::take for taking the value out of a box without deallocating it libs-team#663 (comment)~~
- resolved in Tracking Issue for Box::take #147212 (comment)?

https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

Name idea: into_inner_and_uninit

Rollup merge of rust-lang#147227 - edwloef:box_take, r=joboet

Unrolled build for #147227

@rustbot

@rustbot label -S-tracking-unimplemented

Rollup merge of #147227 - edwloef:box_take, r=joboet

Rollup merge of rust-lang#147227 - edwloef:box_take, r=joboet

Rollup merge of #147227 - edwloef:box_take, r=joboet

Maybe this is not my place to say (or the right place to for that matter), but if this is going to be added, shouldn't there also be a Box::<T>::swap(&mut self, value: T) -> T?

The docs suggest take for reusing a Box in conjunction with write, which sounds like a common enough use case that there should just be a function for it. Using take and write is also rather limited as (due to the nature of both functions), it's not possible to swap a box you do not own.

Maybe this is not my place to say (or the right place to for that matter), but if this is going to be added, shouldn't there also be a Box::<T>::swap(&mut self, value: T) -> T?

just use mem::replace

Oh yeah, I suppose that works

I'd like to get the ball rolling on getting this stabilized. I assume the unresolved question needs to be resolved beforehand, so here goes.

In the original message suggesting that take might not be the best name, it was mentioned that the name take was already a bit overloaded, doing different things across the standard library:

ManuallyDrop::take: duplicate the old value, leave soundness to caller
{mem, Option, Vec, Cell, RefCell}::take: take the old value and leave Default::default
{OnceCell, OnceLock}::take: take the old value and leave empty slot to be lazily re-initialized
{HashSet, BTreeSet}::take: take the old value and leave empty slot in collection
Iterator::take, Read::take: limit stream to specific item count

Of those, I believe Box::take would be closest to the behavior of Option::take with Box<Option<T>>, except with the "value" and "no value" states being separate types instead of Some and None enum variants, making it infallible. Therefore I'd say the name sort-of mirrors alternatives that do similar things that already exist in std.

The alternative that would most closely mirror its counterpart, Box::write, is Box::read, but that already exists through impl<R: Read + ?Sized> Read for Box<R>. I'm not sure whether the resolution/inference pain is worth the name here.

I'm personally somewhat meh on into_inner_and_uninit, mainly because there's no other into_inner_and_* in the standard library anywhere, it's not a name I would think of if I wanted that functionality. I'm happy to hear counterarguments to that though.

FWIW I suggested a different name for discussion but I actually like take. It fits the common semantic of removing a value from something. The signature here is a bit peculiar, but it's really just the logical conclusion of taking from a Box.

Oh, good to hear 😄 so I guess this is just waiting on libs to agree then?

Rollup merge of #147227 - edwloef:box_take, r=joboet

Rollup merge of rust-lang#160436 - edwloef:stabilize-box-take, r=Dark…

Unrolled build for #160436 in rollup 163178

Rollup merge of rust-lang#160436 - edwloef:stabilize-box-take, r=Dark…

Navigation Menu

Repository navigation

Tracking Issue for `Box::take` #147212

Public API

Steps / History

Unresolved Questions

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for Box::take #147212

Description

Public API

Steps / History

Unresolved Questions

Footnotes

Activity

camsteffen commented on Oct 1, 2025

edwloef commented on Oct 2, 2025

3 remaining items

Fisch37 commented on Jan 1, 2026

programmerjake commented on Jan 1, 2026

Fisch37 commented on Jan 1, 2026

edwloef commented on Mar 20, 2026

camsteffen commented on Mar 21, 2026

edwloef commented on Mar 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking Issue for `Box::take` #147212