Rust: Tracking issue for by-value array iterator (feature `array_value_iter`)

[LukasKalbertodt]

This is a tracking issue for core::array::IntoIter. Implemented in https://github.com/rust-lang/rust/pull/62959.

Blocked by:

• [ ] Const generics (https://github.com/rust-lang/rust/issues/44580)

Unresolved questions:

• [ ] Can/should we add an IntoIterator impl for arrays? (see #65819 to discuss)
• [ ] Do we want to add a method like owned_iter to arrays (returning array:IntoIter) ?

[rustbot]

Error: Label B-unstable can only be set by Rust team members

Please let @rust-lang/release know if you're having trouble with this bot.

[CryZe]

For an IntoIterator impl we should probably issue warnings as soon as possible (not just via clippy).

[LukasKalbertodt]

Can we even stabilize this before stabilizing const generics? No, right? Because the public API clearly contains parts of const generics. Or is it possible to stabilize because the only way programmers can interact with the type is not dependent on const generics?

Also: could we add the IntoIterator impl for arrays without stabilizing this (the std::array::IntoIter type)? As the PR showed, people can use the iterator without the #![feature(array_value_iter)]. The unstable feature is just required to name the type. But it also seems strange to have a (necessarily) stable impl that uses an unstable type.

[SimonSapin]

Right, unlike impls like for example impl<T: Eq, const N: usize> Eq for [T; N] where [T; N]: LengthAtMost32 {} which we could revert to 32 separate macro-generated impls, array::IntoIter is a generic type that has a const paramater which couldn’t be represented if we ever came to remove const generics from the language.

[LukasKalbertodt]

@SimonSapin Just to be sure I understand you correctly, what is your answer to this question?

Could we add the IntoIterator impl for arrays without stabilizing std::array::IntoIter?

Using the impl without #![feature(array_value_iter)] works, but it seems strange to me that we can "use" an unstable type as long as we don't name it. On the other hand, since the IntoIterator impl is bound by LengthAtMost32, if const generics were to be removed, we could simply add 32 different iterator types to the standard library. Right? So in theory we could add the impl? Is there some precedence to this?

[SimonSapin]

My previous comment was saying that we cannot stabilize a struct IntoIter<const N: usize, T> {…} type without definitely relying on const generics, because the const parameter is visible in that signature. Adding a where [T; N]: LengthAtMost32 bound is not enough, unlike for trait impls.

---

Additionally, cross-posting from https://github.com/rust-lang/rust/pull/65819#issuecomment-600872147:

With my Libs team hat on: I’d be uncomfortable stabilizing a method that returns an unstable type. Yes this does mean blocking array by-value iterators on const generics. (Or stabilizing an array trait and a const-generics-free iterator type.)

https://github.com/rust-lang/rust/labels/F-const_generics shows active work. It’ll come. In the meantime, as @mpdn mentioned the arrayvec crate provides an alternative.

[Plecra]

The DoubleEndedIterator implementation seems counter-intuitive to me. I was under the impression that the trait was typically implemented where it could be done in a zero-cost way, like how slices are required to track their length anyway. Many of the std iterators could implement more of the iterator traits if they just tracked more state.

Is the DoubleEndedIterator implementation particularly urgent? Maybe it doesn't need to be stabilized with the main Iterator implementation...

[cuviper]

I think it would be strange if array::IntoIter didn't implement DoubleEndedIterator, as it would be deficient compared to slice and Vec iterators. There are plenty of standard iterators that already track extra state to support reversing -- e.g. FlatMap would be a lot simpler if it didn't need that.