ACP: IntoIterator for Box<[T]>

[clarfonthey]

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.

[cuviper]

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.

For arrays, the edition hack was only about what array.into_iter() resolved to. We did not make different behavior for more direct use of <[T; N] as IntoIterator>::into_iter. This is documented here:
https://doc.rust-lang.org/std/primitive.array.html#editions

[clarfonthey]

Ahh, I didn't actually know those specifics about the edition hack. I'm honestly not even sure if a hack would be required in this case, but I figured I would make an ACP and talk about it since I remembered that being a contentious issue at the time. Maybe a crater run would just show that I'm being overly cautious.

[cuviper]

It definitely is an analogous situation, that boxed_slice.into_iter() will currently auto-deref to a slice iterator. Maybe crater will reveal that this is uncommon, but it was definitely an issue with arrays.

Also, I just remembered that I tried this before and failed due to Iterator for Box<I>: rust-lang/rust#59878 (comment)

[ChayimFriedman2]

@cuviper Negative impls can now make this possible by impl<T> !Iterator for [T], like we impl !Error for &str.

[Amanieu]

We discussed this in the libs-api meeting. We're happy with this change since it is clearer the "more correct" behavior for Box<[T]>::into_iter.

This should be tried with a crater run first. If breaking changes are too significant then a workaround could be prepared for the 2024 edition (it's not yet clear what this would involve, it depends on the crater results).