By the way, something I don't understand.
So it lets me do this.
"array" is unused, it gives me an unused var warning.
but… it *can't* be used?!
I didn't initialize it, you can't read an uninitialized var, and it isn't mut so I can't write into it.
Why does it LET me define it?
Conversation
Ohh
read image description
ALT
3
7
This statement in the reference for "slice" is what I want, but also it is bad. Are there (safe) steps I can take to reliably ensure bounds-checking for a particular use of a slice is removed before runtime? Are the rules for this documented somewhere (such as the rustc manual)?
6
4
Like what I'm looking for is some way to type or decorate a site such that I'm asserting "I think I followed the rules to get a no-boundcheck optimization here, and if I messed up, I want the compiler to tell me so"
4
8
Several people replying "use iterators". Good approach, but here's a complication:
I often find myself in a situation where I have 2 arrays, incidentally of the same length.
int a:[T], b:[T];
I want to iterate over "both at once". For example produce a c such c[i] = a[i] + b[i]
1
7
Using the iterator syntax (which remember, I want to use because I want the language-level guarantee I'm avoiding bounds checks), is there a way to iterate over 2 arrays (or iterate up to end of shorter array)? In C I'd do this by iterating over key range and random indexing.
7
5
Replying to
Iterators are almost entirely library feature. The language provides some syntactic sugar via `for` loops.
The standard library's slice iterator has start and end pointers with the core iterator next method implemented as advancing by an element and comparing to the end pointer.
1
1
Replying to
If it happens to be the case that the standard library iterators will always follow the code path that removes the bounds checks at individual index sites, and this is a strong and universally understood social contract, that's "as good as" a lang guarantee for now i think
4
3
Yeah it's pretty widely understood in the community that if you're using iterators, you'll get bounds checks elided -- and any cases where that doesn't happen are a compiler bug
2
2
There aren't bounds checks to elide for the slice iterator. It's not that they're being elided but rather that the library implementation of the slice iterator uses a start and end pointer with unsafe code so you end up with the same kind of code as with a pair of C++ iterators.
3
1
1
Simple iterator adaptors are also quite efficient since inlining can be relied upon to work well. It's simply what you get from the basic `fn next(&mut self) -> Option<Self::Item>` protocol. Sophisticated adaptors and more complex container iterators aren't necessarily efficient.