> Arrays do have an advantage however, compilers can see their size
Wouldn’t vectors have the same advantage in Rust? If we’re iterating over a vector, it’s proveable at compile time that the length is not being modified during the iteration.
Wouldn’t vectors have the same advantage in Rust? If we’re iterating over a vector, it’s proveable at compile time that the length is not being modified during the iteration.
let arr = [1, 2, 3, 4];
// Will not compile a bound check
let x = arr [3];
let v = vec! [1, 2, 3, 4];
// Imagine other code separates these two lines
// Might compile a bound check
let x = v [3]; fn foo_arr(v: &[u8; 5]) -> u8 {
v[2]
}
fn foo_vec(v: &Vec<u8>) -> u8 {
v[2]
}
In the foo_arr case, the index lookup can be optimized out. In the foo_vec case, it can't be, because theoretically you might pass something with only 2 elements or less to foo_vec, and access to the third element will fail.Same goes for e.g. the slice::windows vs slice::array_windows functions. In windows, you get a slice in the closure, and while the size is guaranteed by the implementation, without there being inlining the optimizer doesn't know about this guarantee. With array_windows, this size guarantee is communicated.