Tracking issue for future-incompatibility lint array_into_iter

[LukasKalbertodt]

What is this lint about?

Method resolution is responsible for finding a fitting method for a method call expression receiver.name(args). The expression array.into_iter() (where array has an array type [T; N]) currently resolves to either <&[T; N] as IntoIterator>::into_iter (for arrays smaller than 33) or <&[T] as IntoIterator>::into_iter (for larger arrays). In either way, an iterator over references to the array's elements is returned.

In the future, we might want to add impl IntoIterator for [T; N] (for arrays by value). In that case, method resolution would prioritize <[T;N] as IntoIterator>::into_iter as that method call would not require an autoref-coercion. In other words: the receiver expression (left of the dot in the method call) fits the receiver type of the method perfectly, so that method is preferred. In the &[T; N] or &[T] case, coercions are necessary to make the method call work.

Since the new method is prioritized over the old ones, some code can break. Usually that code looks somewhat like this:

[1, 2, 3].into_iter().for_each(|n| { *n; });

Currently this works, as into_iter returns an iterator over references to the array's values, meaning that n is indeed &{integer} and can be dereferenced. With the new impl, that code would stop compiling. The lint has been put in place to warn of this potentially upcoming breaking change.

How to fix this warning/error

Replace .into_iter() with .iter(). The latter is guaranteed to always resolve to an iterator over references to the elements.

---

Current status

• Lint merged as warn by default in 1.41 (stable on 2020-01-31): Add future incompatibility lint for array.into_iter() #66017
• Lint also lints boxed arrays starting from 1.42 (stable on 2020-03-13): Generalize array_into_iter lint to also lint for boxed arrays #67524

[est31]

Was hitting this in a private (currently not open source) project of mine. Thanks for introducing this slowly so that it can be caught in time instead of just breaking it!

[Skepfyr]

This lint doesn't trigger for boxed slices (although the corresponding clippy lint does), #59878 suggests it probably should. Is this intentional?

[LukasKalbertodt]

Currently it's intentional because this lint is only about arrays. But it seems reasonable to me to also lint for Box<[T]>, but probably as a new lint and not as array_into_iter. Furthermore, the lint doesn't fire for Box<[T; N]> which it should. I will try to prepare two PRs fixing those two things soon.

[bstrie]

With the edition coming up, has there been discussion about turning lint this into deny-by-default for users of the 2021 edition? Obviously adding a hypothetical impl IntoIterator for [T; N] would affect all editions, but having this pattern be denied in a new edition would be a gradual step toward making that transition gracefully. This is especially relevant now that min_const_generics will be stable in March, which will make fixed-size arrays more ergonomic than ever.

[SimonSapin]

This won’t help with dependencies in the way #71249 would since current versions of these dependencies will still have a previous edition, but this still sounds like a good step.