Some more about step_by() troubles

1

I've had to replace most usages of step_by() in my Nightly code because it's too much slow. I don't know if such performance problem is fixable (currently it generates a messy and very long assembly. This is not acceptable for such basic feature in a system language). Assuming it's fixable I still prefer the older design of step_by().

Forcing all step_by() to be usize disallows backwards stepping:

for i in (a .. b).step_by(-1) {}

And (before I removed all the usages of step_by) I have had to introduce many stupid and bug-prone "as usize" inside step_by.

Also usize is not large enough for all steps (on a 32 bit system you need a much smaller step to overflow usize):

#![feature(iterator_step_by, i128)]
fn main() {
    for i in (0 .. std::u128::MAX).step_by(1_000_000_000_000_000_000_000) {
        println!("{}", i);
    }
    println!();
}

In my code I've seen that the need to step_by on non-numerical ranges is quite uncommon.

Before step_by gets stabilized forever I invite people to think better about its design. Also because such design must allow efficient code.

4 Likes
2