RangeFrom iterator overflows when it gets to the maximum value of the type

[Aatch]

So if you have (0u8..) and iterate over it, it will keep going forever (in a release build anyway), producing 0, 1, 2, ... 255, 0, 1, 2, ...

That is unexpected. It also panics in a debug build, so I assume it's also not intentional. I propose that instead of overflowing, the iterator instead returns None.

[XMPPwocky]

Would that change be backwards compatible? Arguably not, since it changes observable behavior in stable code, and although nobody should be relying on it, you never know.

(For the record, I agree this is surprising, probably wrong, behavior. For example, iterating over (1u8..) will eventually give you 0!)

[Gankra]

CC @nrc (who probably has the best memory on this precise decision)

[nrc]

This is the intentional behaviour. The expectation is that you will only use such iterators along with take() or some other safe guard against overflow. (We basically chose what seemed like the least-worst option here).

[alexcrichton]

I agree with @nrc that this is intended behavior currently. The precise semantics of when the overflow occurs I think is covered by #25708, so I'm going to close this in favor of that. Feel free to reopen if you disagree though!