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
What is this lint about?
Method resolution is responsible for finding a fitting method for a method call expression
receiver.name(args). The expressionarray.into_iter()(wherearrayhas 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_iteras 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:
Currently this works, as
into_iterreturns an iterator over references to the array's values, meaning thatnis 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
array.into_iter()#66017array_into_iterlint to also lint for boxed arrays #67524