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.