-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RangeFrom<u8> stops at 254 #24119
Comments
The problem is the next method of RangeFrom: fn next(&mut self) -> Option<A> {
self.start.step(&A::one()).map(|mut n| {
mem::swap(&mut n, &mut self.start);
n
})
} It returns the previous value, then updates itself to store the next one. The value 255 ends up being the value that represents a "done" state, so it can't return it. I can't think of any solution that doesn't involve adding a |
Or impl IntoIter instead of Iterator (and use a helper struct to keep track of the range). |
Seems similar to #23635. |
Question: What is the origin of this Rust behavior, or what is its justification? e.g.: Why an exclusive upper bound on ranges? This caught me by total surprise, coming from Haskell, and I don't know if any Rust I've written for my own cases is wrong now. It behaves differently from similar syntax in Haskell, Swift, and Go, so I'm wondering if it's fruitful to have behavior different from peer languages (in trying to attract people away from languages where syntax like this does not exist.) |
Ruby has both exclusive and inclusive ranges
|
The origin is related to the for-loop idiom in C. Essentially, it seems like the exclusive behaviour is useful more often than inclusive in a systems language. |
Exclusive behaviour is also a leaner implementation. For inclusive behaviour you need some kind of flag for "now yield the inclusive element". This issue is an exact example of why: How do you statefully write an iterator from |
cc #24120, which adjusts this behavior by triggering an overflow on non-wrapped-arithmetic types; it makes the semantics equivalent to repeatedly updating |
A recent change to the implementation of range iterators meant that, even when stepping by 1, the iterators *always* involved checked arithmetic. This commit reverts to the earlier behavior (while retaining the refactoring into traits). Fixes #24095 Closes #24119 cc #24014 r? @alexcrichton
I tried printing all valid
u8
s by doingand was surprised to find it only printed up to 254.
I'm unsure if this is supposed to be this way (
range_inclusive
can be used). If so, I'd propose adding this to the Iterators/Ranges section of the book.The text was updated successfully, but these errors were encountered: