Tracking Issue for Box::into_boxed_slice

[elichai]

This is a tracking issue for Box::into_boxed_slice.
The feature gate for the issue is #![feature(box_into_boxed_slice)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Implement the feature -- Add a function to turn Box<T> into Box<[T]> #71421
• Adjust documentation (see instructions on rustc-dev-guide)
• Stabilization PR (see instructions on rustc-dev-guide)

[programmerjake]

seems to me that it would be better to instead have the function convert from Box<T> to Box<[T; 1]> since that's the minimal unsafe part, allowing the function to be more general, and since safe code can easily coerce the result to Box<[T]> if needed.

[m-ou-se]

Can this be a From impl instead?

[elichai]

@m-ou-se Yes! the only reason this isn't a From impl is because From are insta-stable: #71421 (comment)

[elichai]

This will also be super useful for Rc/Arc
@m-ou-se Where/How can I discuss turning these into a From impl? (with the insta-stable implications)

[zachs18]

Making this a From impl would conflict¹ with existing From<Box<Local>> for Box<[Local]> impls, since Box is #[fundamental] and thus treated like its pointee for coherence purposes in most cases. (Similarly, std::{array,slice}::from_{ref,mut} becoming From impls would be breaking.)
I don't think adding From<Rc<T>> for Rc<[T]> or for Rc<[T; 1]> (or Arc) would have the same issue, since Rc/Arc are not #[fundamental].

Also, we could add alloc::array::from_boxed(_: Box<T>) -> Box<[T; 1]> and alloc::slice::from_boxed(_: Box<T>) -> Box<[T]> analogous to from_ref/from_mut instead of or in addition to having associated fn(s) on Box.

Footnotes

1. I suppose a crater run could be done to see if such implementations are common, but I think this would count under the "adding a fundamental trait impl is a major change" section of the API Evolution RFC and might not be allowed regardless. ↩