It was one of the things that makes me surprised when I learn Rust. Why can’t I write for v in [a, b, c] { .. }? I think this is due to the lack of const generics, but I can’t be sure. If anyone knows the historical context about it, please let me know
Anyway, we’re expecting that const generics will be land to stable soon™. With this feature It’s trivial to write impl IntoIterator for [T; N] in libcore. But, is it semver compatible? Or we don’t have any hope for it and should use for v in ArrayVec::new([a, b, c]) forever?
This is an inference and trait resolution change, which is explicitly not considered to be a breaking change in Rust’s promise.
I’m sure this will cause some churn when we get it, but my_array.into_iter() is longer than .iter(), so we can start pushing people to be future-compatible ASAP. And the trait is too important to not add.
Simply adding the impl causes widespread breakage, to the extent that we don’t just want to YOLO add it. There’s some work on figuring out a transition story here: https://github.com/rust-lang/rust/pull/49000
fn main ()
{
let a = [0_i32];
let mut iterator = a.into_iter();
/* // unsugars to:
let mut iterator = IntoIterator::into_iter(&a); // &[i32] : IntoIterator<Item = &i32>
// since `IntoIterator::into_iter(a)` is not valid, which "triggers an autoref" */
let _: Option<&i32> = iterator.next();
}
So, if [T] were to impl IntoIterator, then IntoIterator::into_iter(a) would be valid, “autoref would not trigger” and the above code would fail to compile.