Tracking Issue for edition-dependent IntoIterator for arrays

[m-ou-se]

• array::IntoIter type: Tracking issue for by-value array iterator (feature array_value_iter) #65798
• Idea to make .into_iter() resolution edition dependent: exploration: ignoring arrays in method dispatch #84133
• FCP: Cautiously add IntoIterator for arrays by value #84147 (comment)
• IntoIterator implementation for arrays: Add IntoIterator impl for arrays by value (for [T; N]) #65819 Included in Cautiously add IntoIterator for arrays by value #84147
• Ignore the by-value .into_iter() in method resolution on Rust 2015 and Rust 2018: Cautiously add IntoIterator for arrays by value #84147
• Update array_into_iter lint.
  • Change the "might change in the future" wording: Update array_into_iter lint for 1.53 and edition changes. #85682
  • Correct wording for the current situation in the message (arrays do implement the trait, the method is just hiding itself in a.into_iter() syntax for backwards compatibility): Update array_into_iter lint for 1.53 and edition changes. #85682
  • Also suggest just removing .into_iter() in for a in [1, 2, 3].into_iter(), since that now works on all editions: Update array_into_iter lint for 1.53 and edition changes. #85682
  • Also suggest IntoIterator::into_iter(array): Update array_into_iter lint for 1.53 and edition changes. #85682
  • Extend lint to also cover this case and this case? Upgrade array_into_iter lint to include Deref-to-array types. #88512
• Update documentation
  • Update array and iterator docs in std / core for new IntoIterator impl and edition. #87701
    • Point out that behaviour might be switched on 2015 and 2018 too one day - Point out that behavior might be switched on 2015 and 2018 too one day #84590
    • Fix docs of array::IntoIter::new (the ".. in the future, after .." part): Update outdated docs of array::IntoIter::new. #88610
    • Update docs of the array primitive type - Update primitive docs for rust 2021. #88613
  • Update the book (e.g. this section and probably more, and many examples).
• Update standard library
  • Remove usages of array::IntoIter::new: Update standard library for IntoIterator implementation of arrays  #85930
  • Update expressions like like .chain(array.iter().cloned()) to just .chain(array) since that now works on all editions. (Same for zip, extend etc.): Update standard library for IntoIterator implementation of arrays  #85930
  • Use .extend(array) and from_iter(array) wherever that simplifies things.
  • Remove arrays do not yet implement IntoIterator message from Iterator trait: Remove arrays/IntoIterator message from Iterator trait. #85670
  • Remove for _ in [start..end] messages from Iterator trait. (Could use a new clippy lint?): Remove Iterator #[rustc_on_unimplemented]s that no longer apply. #85689
• Deprecate array::IntoIter::new (IntoIterator::into_iter([1,2,3]) now works too on all editions.): Deprecate array::IntoIter::new. #88611

Once edition 2021 is stable:

• Update examples like this to use arrays by value. (Some(&1) → Some(1) etc.)
  • Update examples to no longer avoid iterating arrays. (Many doctest examples are using iterators over e.g. &i32 instead of just i32.)
• Remove about 200 usages of .iter().copied() and .iter().cloned() from examples and tests.

Unresolved questions:

• Do something about the 'copying large arrays' footgun. (Add IntoIterator implementation for Box<[T; N]> etc? Add lint about big copies?)

[cuviper]

Add IntoIterator implementation for Box<[T; N]> etc?

I think it would be great if that could produce vec::IntoIter<T>, but it gave me an upstream coherence error when I tried in #59878 (comment), core being upstream of alloc.

     = 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

[mominul]

I'd like to tackle the standard library changes first!
@rust-highfive assign

[weihanglo]

Also suggest just removing .into_iter() in for a in [1, 2, 3].into_iter(), since that now works on all editions.

Since for loop are converted into loop in HIR, is it still possible implementing this as a late pass lint rule?

[k0pernicus]

I could work on updating the array_into_iter lint.
However, as I never touched to this part before I may have some questions later...

[nikomatsakis]

I'm going to break this issue apart into sub-issues to help in people signing up for specific bits!

[m-ou-se]

I'd like to tackle the standard library changes first!

@mominul Which changes specifically do you mean? Have you started working on these?

[mominul]

@m-ou-se I haven't started yet, but I intend to work on the Update standard library checklist items:

• Remove usages of array::IntoIter::new.
• Update examples to no longer avoid iterating arrays. (Many doctest examples are using iterators over e.g. &i32 instead of just i32.)
• Update expressions like like .chain(array.iter().cloned()) to just .chain(array) since that now works on all editions. (Same for zip, extend etc.)
• Use .extend(array) and from_iter(array) wherever that simplifies things.
• Remove arrays do not yet implement IntoIterator message from Iterator trait.

[m-ou-se]

Thanks! Since we're running a bit short on time for the edition changes, I'm implementing the most important ones today. Hope you don't mind. I'll add the PR numbers in the first comment above, so take a look there before you start implementing anything to avoid doing work twice.

[mominul]

@m-ou-se Thanks, I will! 😊

[joshtriplett]

The lang portion of this has stabilized and shipped, so un-tagging lang. libs-api may wish to continue tracking this for the proposed documentation changes.