I feel that in your posts here and in other threads, you are hating on iterators for no good reason. In the thread I'm aware of, you had an experience where Clippy, frankly, misled you to use iterators in a place where they were inappropriate, because you were doing random access, which is the opposite of an appropriate use for iterators, but that's a different rant, and from this experience you seem to have drawn the conclusion that iterators are just always slow.
When you use iterators for iterating over slices, they omit bounds checks, which lets you write code that is as fast or faster than index-based iteration with the guarantee of safety. You don't have to rely on the optimizer or
unsafe to elide bounds checks when using iterators. This is the case whether or not you "like" the resulting code. Yes, there are examples in this forum of taking a three-line loop and, under the guise of making it "more idiomatic", writing a 10-line quasi-"functional" monstrosity with control flow that bounces back and forth three times, and I agree that we shouldn't encourage that. But "avoid iterators" is at least equally wrong.
Iterators are a tool like any other: they have appropriate and inappropriate uses. The other thread I linked was clearly an inappropriate use for an iterator. This one is clearly appropriate; in fact, it's basically the ideal iterator:
It moves through the data structure in a systematic manner, visiting each element only once.
It has no need for bounds checks because there is no direct indexing.
(not sure why nobody mentioned
flatten() yet. Maybe it hasn't been in the stdlib long enough to soak into the collective consciousness)
That said, you have a really good point here:
Although you can only use a 2D array when the dimensions are known at compile-time, which is not most of the time in my experience, you can still normally get performance wins, for non-jagged arrays, by using a flat
Vec and indexing into it with something like
i*width + j.