Repository navigation
Tracking issue for by-value array iterator (feature array_value_iter) #65798
Description
This is a tracking issue for core::array::IntoIter. Implemented in #62959.
Blocked by:
- Const generics (Tracking issue for const generics (RFC 2000) #44580)
Unresolved questions:
- Can/should we add an
IntoIteratorimpl for arrays? (see AddIntoIteratorimpl for arrays by value (for [T; N]) #65819 to discuss) - Do we want to add a method like
owned_iterto arrays (returningarray:IntoIter) ?
Reacted by mqus, Stanislav Tkach, Benjamin Levy, Solomon Ucko, Shaun Jackman, museun, Eyal Kalderon, Willow Chargin, Shane F. Carr, AlephAlpha and 1 more
Reacted by Wesley Norris, Mara Bos, Guillaume Depardon, foobles, Hyeonu Park, Jonas Schievink, Iago-lito, Benjamin Levy, Shaun Jackman, museun and 1 more
Activity
rustbot commentedon Oct 25, 2019
CryZe commentedon Oct 25, 2019
For an IntoIterator impl we should probably issue warnings as soon as possible (not just via clippy).
LukasKalbertodt commentedon Nov 4, 2019
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
IntoIteratorimpl for arrays without stabilizing this (thestd::array::IntoItertype)? 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 commentedon Nov 4, 2019
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::IntoIteris 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 commentedon Nov 8, 2019
@SimonSapin Just to be sure I understand you correctly, what is your answer to this question?
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 theIntoIteratorimpl is bound byLengthAtMost32, 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 commentedon Mar 19, 2020
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 awhere [T; N]: LengthAtMost32bound is not enough, unlike for trait impls.Additionally, cross-posting from #65819 (comment):
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.)
F-const_generics`#![feature(const_generics)]`
shows active work. It’ll come. In the meantime, as
@mpdnmentioned the arrayvec crate provides an alternative.Plecra commentedon Aug 7, 2020
The
DoubleEndedIteratorimplementation 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 thestditerators could implement more of the iterator traits if they just tracked more state.Is the
DoubleEndedIteratorimplementation particularly urgent? Maybe it doesn't need to be stabilized with the mainIteratorimplementation...cuviper commentedon Aug 7, 2020
I think it would be strange if
array::IntoIterdidn't implementDoubleEndedIterator, as it would be deficient compared to slice andVeciterators. There are plenty of standard iterators that already track extra state to support reversing -- e.g.FlatMapwould be a lot simpler if it didn't need that.KodrAus commentedon Nov 26, 2020
Have we done any crater runs recently on where the lint has landed us? If not, would anybody be interested in opening up an experimental PR to check?
LukasKalbertodt commentedon Nov 26, 2020
The last crater run AFAIK was this one. The problem is that crater doesn't seem to update the
Cargo.lock(also see this comment. This means there are still a ton of non-root regressions that can be fixed by a simplecargo update. Also take a look at my comment here, where I estimate that roughly 4000 of the 4771 regressions crater found would be trivially fixable.It would be really beneficial if we could update (or remove) the
Cargo.lockon the crater machines, but I'm not sure how easy that would be.If you want to run crater again, I can just update my PR again. Or are you mentioning "experimental PR" to reduce noise on the main PR?
SimonSapin commentedon Dec 28, 2020
This is unblocked! #79135 has landed. What remains here is to decide how should one obtain an
array::IntoItervalue:impl IntoIterator for [T; N]AddIntoIteratorimpl for arrays by value (for [T; N]) #65819. The status there is that this PR would still cause some regressions: AddIntoIteratorimpl for arrays by value (for [T; N]) #65819 (comment)array::IntoIter::new, with the option to deprecate it afterIntoIteratorcan be implemented.into_iter) and replacenewwith an inherent method on arrays, also with the option to deprecate afterIntoIteratorcan be implementedStabilize by-value `[T; N]` iterator `core::array::IntoIter`
SimonSapin commentedon Dec 29, 2020
@scottmcm weighed in on Zulip: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/array.20by-value.20iterator.20stabilization/near/221116093
Sounds good to me. I’ve submitted a stabilization PR and requested FCP: #80470
SimonSapin commentedon Jan 31, 2021
Stabilized in 1.51.0 by #80470.
The
IntoInteratorimpl is tracked separately at #65819.Require rustc 1.51+ for `IndexMap::from(array)` and `IndexSet::from(a…
Require rustc 1.51+ for `IndexMap::from(array)` and `IndexSet::from(a…
Require rustc 1.51+ for `IndexMap::from(array)` and `IndexSet::from(a…