Suggestion of explicit_infinite_iterator for OneSidedRange

[alpaylan]

What it does

For a given iterator using a one sided range (i..) where i: T it suggests changing it with (i..T::Max).cycle() in the interest of explicitness.

Advantage

• Remove divergence between debug and release builds(right now, the following code fails with overflow in debug, but goes into infinite loop in release mode.

fn main() {
    for i in 0_u8.. {
        println!("{}", i);
    }
}

• It prevents unintentional infinite loops, aiding infinite_iter and maybe_infinite_iter

Drawbacks

It suggests a change in behavior for the debug build.

Example

fn main() {
    for i in 0_u8.. {
        println!("{}", i);
    }
}

Could be written as:

fn main() {
    for i in (0_u8..u8::MAX).cycle() {
        println!("{}", i);
    }
}

[RGBCube]

It suggests a change in behavior for the debug build.

Not just the debug build, as release mode will now actually terminate.

This would be a pretty neat "you probably didn't want to do that" lint

[kulkalkul]

It suggests a change in behavior for the debug build.

Not just the debug build, as release mode will now actually terminate.

This would be a pretty neat "you probably didn't want to do that" lint

Some extra: there is also a mention of "Range literal construction without an upper bound" in a Clippy issue: #9699. Existing maybe_infinite_iter isn't working as expected because it isn't implemented for loops. But I agree with @RGBCube, most basic case of 0.. should be its own lint on rustc lint with "you probably didn't want to do that" message & deny by default.