Tracking Issue for `box_into_inner`

[crlf0710]

Feature gate: #![feature(box_into_inner)]

This is a tracking issue for consuming a Box and returning its wrapped value.

The language actually supports *x as a special case. However it can't be generalized to other types easily. It also doesn't consume the Box value immediately if T is Copy, which is quite a footgun.

An explicit version is added here to make the API more consistent with Pin, Cell, RefCell etc.

Public API

impl<T, A: Allocator> Box<T, A> {
     pub fn into_inner(boxed: Self) -> T;
}

Steps / History

• Implementation: Add Box::into_inner. #80438
• Improve documentation for Box::into_inner #98523
• Final commenting period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[fosskers]

How come it's a function and not a method?

[crlf0710]

@fosskers https://rust-lang.github.io/api-guidelines/predictability.html#smart-pointers-do-not-add-inherent-methods-c-smart-ptr

[conradludgate]

When looking at how to turn a box back into a stack owned value, I find this function, but in my case the *x method works perfectly fine. It's documented in the box module, but I feel like it should be doubly documented here as a simpler alternative.

[TehPers]

Somewhat minor, but I like that Box::into_inner can be used in method chains without requiring a closure. .map(|x| *x) is still shorter than .map(Box::into_inner), but the latter more clearly describes what you're doing in my opinion. It can also help the compiler infer the type in the iterator/Option<T>/whatever at that point in the method chain for what it's worth. Otherwise you'd have to write |x: Box<_>| *x for the same effect.

[BurntSushi]

Box::into_inner appears to have been around for a while, and I don't see any obvious issues with it? What do others think?

@rfcbot merge

[rfcbot]

Team member @BurntSushi has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @cramertj
• @dtolnay
• @joshtriplett
• @m-ou-se
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.