You mean implicitly? I am aware that idiomatic Rust strongly prefers iterators over indices for performance, but in my case, the only place where it really matters is when counting pixels to draw, and there is no kind of collection there, just x,y numbers.

▲

nextaccountic 2 days ago | parent [-]

Yep implicitly, for receives an IntoIterator, so it iterates either on an iterator like 0..10 or something that can be converted into an iterator like &myvec

(Note that it was a severe design flaw to make ranges like 0..10 iterators directly rather than just IntoIterator, because this means ranges can't be Copy and as such it's inconvenient to pass them around.. but fortunately they are going to fix that in a new edition)

But actually..

Do you mean you prefer writing for i in 0..myvec.len() and then accessing myvec[i], rather than using for x in &myvec or for x in &mut myvec, and using the x directly? But why?

	▲	mvx64 a day ago \| parent [-]
		Interesting, I will look more into this. To be honest, grepping the source, I found a couple of places with for x in &myvec. Probably tried them while learning the language, they worked and left them there. But really, I am just more used to the old way. It visually feels more familiar, I have an explicit i to do things, and it's easier to delete/manipulate elements while in the loop and not invalidate anything. It's not that I am against an iterator if it matters and it's better, of course. In my case, the important loops are like "for i in x0..x1 { draw(i, y); }". Is there a way to turn this into something that, for example, skips the bound checks or optimizes it in any other way?