You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
RangeFrom iterator overflows when it gets to the maximum value of the type #25696
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.
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!)
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).
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!
Activity
XMPPwocky commentedon May 22, 2015
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 commentedon May 22, 2015
CC @nrc (who probably has the best memory on this precise decision)
nrc commentedon May 23, 2015
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 commentedon May 26, 2015
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!