Box<[T]> should have an IntoIter implementation.

[emilio]

Right now the only way to move out of a Box<[T]> is using into_vec, which is a bit inconvenient. Is there any reason Box<[T]> shouldn't implement IntoIter?

[SimonSapin]

Unfortunately this has the same issue as #25725: boxed_slice.into_iter() works today through auto-deref (then auto-ref?) to <&[T] as IntoIterator>::into_iter, so adding this impl would change the meaning of (some) existing code.

Whatever we end up deciding should probably apply to both.

CC @rust-lang/libs

[SimonSapin]

Unlike with arrays though, this case has a work-around in converting though Vec<T>.

[scottmcm]

So we could add the implementation today, using Vec::from(self).into_iter() to make a vec::IntoIter? Seems like there wouldn't even be a need to make a new iterator type...

[cuviper]

The user could work around this by going through Vec, and the nice thing is that this has no real cost -- it's just a bit awkward.

But if std did this, we would run into the same problems as arrays, where calling into_iter() today on a Box<[T]> gets you a slice::Iter. So it's a breaking change to add IntoIterator -- technically minor and allowable, but needs caution.

[SimonSapin]

@scottmcm Yes, the implementation is easy and does not require a new type. The concern is only in the change being breaking.

[LukasKalbertodt]

@SimonSapin Do you think it would be a good idea to add a future-incompatibility lint for this, like we did for the array.into_iter() problem (#66145)? In particular, because you said "Whatever we end up deciding should probably apply to both." This was suggested here.

[cuviper]

FWIW, I just tried adding Box<[T]> and Box<[T; N]> to see what would break, and they fail immediately:

// library/alloc/src/boxed.rs

#[stable(feature = "boxed_slice_into_iter", since = "1.53.0")]
impl<T, A> IntoIterator for Box<[T], A> {
    type Item = T;
    type IntoIter = crate::vec::IntoIter<T, A>;

    #[inline]
    fn into_iter(self) -> Self::IntoIter {
        todo!()
    }
}

#[stable(feature = "boxed_array_into_iter", since = "1.53.0")]
impl<T, A, const N: usize> IntoIterator for Box<[T; N], A> {
    type Item = T;
    type IntoIter = crate::vec::IntoIter<T, A>;

    #[inline]
    fn into_iter(self) -> Self::IntoIter {
        todo!()
    }
}

error[E0119]: conflicting implementations of trait `core::iter::IntoIterator` for type `boxed::Box<[_], _>`:
    --> library/alloc/src/boxed.rs:1578:1
     |
1578 | impl<T, A> IntoIterator for Box<[T], A> {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: conflicting implementation in crate `core`:
             - impl<I> IntoIterator for I
               where I: Iterator;
     = note: upstream crates may add a new impl of trait `core::iter::Iterator` for type `[_]` in future versions

error[E0119]: conflicting implementations of trait `core::iter::IntoIterator` for type `boxed::Box<[_; _], _>`:
    --> library/alloc/src/boxed.rs:1589:1
     |
1589 | impl<T, A, const N: usize> IntoIterator for Box<[T; N], A> {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: conflicting implementation in crate `core`:
             - impl<I> IntoIterator for I
               where I: Iterator;
     = note: upstream crates may add a new impl of trait `core::iter::Iterator` for type `[_; _]` in future versions

This has to do with impl<I: Iterator + ?Sized, A> Iterator for Box<I, A> to complete the conflict, although we know that we would never add direct Iterator for [T] or [T; N]. I don't know if we could hack around that with a lang item or something.