5 ms·
> for i in 0..(xs.len()) { let x = xs[i]; // do something with x } > should really be this: > for x in &xs { // do something with x } I am curious
by blinkingled 9y ago
> for i in 0..(xs.len()) {
let x = xs[i];
// do something with x
}
> should really be this:
> for x in &xs {
// do something with x
}
I am curious why the compiler can't rewrite the former to the latter?
- tatterdemalion 9y agoA Sufficiently Smart Compiler would be able to. The second just increments a pointer which starts at the first elem of the array; the first increments a counter and then uses it as an offset into the array, which is bounds checked (the second never generates bounds checks). Proving that that counter never exceeds the end of the array, so the bounds check can be dropped, is not trivial.
- pcwalton 9y agoBecause in the former case, the optimizer has to prove that the length of the array cannot change during the body of the loop, while in the latter case, that's guaranteed by the language semantics.
- masklinn 9y agoAlso because the iterator could do something completely different from an iteration by sequential index no?
- mindleyhilner 9y agoDoesn't `let x = xs[i]` immutably borrow from xs? So for the duration of x's lifetime (which is the entire for-body block), xs cannot be changed and therefore its length must remain the same. Though this might be information that rustc knows about but not LLVM.
- pcwalton 9y agoIn the case of "let x = &xs[i]" it would immutably borrow. But we'd need more MIR optimizations to make use of that fact.
- tom_mellior 9y agoAt least in simple cases, it generates almost identical code for both: https://godbolt.org/g/twuLd1 https://godbolt.org/g/twuLd1 (I may have gotten something wrong, this is my first Rust program! Yay!)