Proposal

Problem statement

Right now, calling <Box<[T]>>::into_iter has the same issue that <[T; N]>::into_iter had prior to Rust edition 2021: it takes the box by reference instead of by value, since it implicitly refers to the implementation of <&[T]>::into_iter.

However, this can be done by-value by converting the Box to a Vec first, returning vec::IntoIter instead.

Motivating examples or use cases

Boxed slices can be used in many of the same places as Vecs, and they have much of the same use cases, which means they should have the same behaviour.

Solution sketch

IntoIterator for Box<[T]> would be implemented, providing the following definition:

impl<T> IntoIterator for Box<[T]> {
    type IntoIter = vec::IntoIter<T>;
    type Item = T;
    fn into_iter(self) -> vec::IntoIter<T> {
        self.into_vec().into_iter()
    }
}

However, this would likely require per-edition inference like the exception made for IntoIterator for [T; N], only properly working on an edition bump. Namely, on the current edition, <Box<[T]>>::into_iter would call the <&[T]>::into_iter definition instead, and only on future editions would it call <Box<[T]>>::into_iter. Older-edition code would have to call into_vec().into_iter() instead.

Alternatives

The main alternative is to do nothing, since the possible alternative is only slightly longer.

(Old edition example):

let my_boxed_slice: Box<[u32]> = Box::new([1, 2, 3]);
for item in my_boxed_slice.into_vec() {
    // do something
}

(New edition example):

let my_boxed_slice: Box<[u32]> = Box::new([1, 2, 3]);
for item in my_boxed_slice {
    // do something
}

Links and related work

None known.

What happens now?

This issue is part of the libs-api team API change proposal process. 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.