-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Change RangeInclusive to a three-field struct. #51622
Conversation
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
r? @SimonSapin |
This comment has been minimized.
This comment has been minimized.
src/libcore/ops/range.rs
Outdated
#[stable(feature = "inclusive_range", since = "1.26.0")] | ||
impl<Idx: PartialEq> PartialEq for RangeInclusive<Idx> { | ||
fn eq(&self, other: &Self) -> bool { | ||
self.start == other.start && self.end == other.end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure you don't need to compare is_iterating
? Consider:
let a = 0..=0;
let mut b = a.clone();
assert_eq!(a, b);
assert_eq!(b.next(), Some(0));
assert_eq!(b.next(), None);
assert_eq!(a, b); // yes or no?
Currently that last assert would fail, because an exhausted range is replaced by 1..=0
. I think with your new code, they will look equal, only different by their is_iterating
.
Another one to consider:
let a = 1..=10;
let mut b = 0..=10;
b.next();
assert_eq!(a, b); // same `start` and `end`, different `is_iterating`
I guess is_empty()
is the better value to use for PartialEq
and Hash
, but that needs PartialOrd
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On this other hand, do we expect this to always be true?
fn reflexive(r: RangeInclusive) -> bool {
r == (r.start()..=r.end())
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Imo, it would be quite jarring if it were not always true..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed with @SimonSapin and @Centril that taking is_iterating
into account when comparing is strange. At the very least we need to modify the impl Debug
to expose is_iterating
if we do want to make the field significant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On this other hand, do we expect this to always be true?
fn reflexive(r: RangeInclusive) -> bool {
r == (r.start()..=r.end())
}
That works in the status quo because the range is changed to 1..=0
when the iterator is exhausted. But it troubles me that with this change, r
and r.start()..=r.end()
might compare equal yet not produce the same items, if r
is exhausted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. Both "compares equal when reconstructed form accessors" and "yields the same items if compares equal" seem desirable, but we can’t have both with this PR’s three-fields design.
I think the I can review for correctness in a bit, but I really don’t have an opinion on whether this change is desirable in the first place. |
Seems like yes, I can't find other uses of these two methods in this repo. These two functions were added by #34530 as substitute of |
cc #51601, these two PRs are going to silently conflict with each other. |
This comment has been minimized.
This comment has been minimized.
08e3aad
to
b0e29d9
Compare
This comment has been minimized.
This comment has been minimized.
b0e29d9
to
5c80508
Compare
This comment has been minimized.
This comment has been minimized.
5c80508
to
4941579
Compare
Turns out LLVM 3.9 cannot recognize the loop. LLVM 6.0 is fine. Not sure about LLVM 4.0. |
@kennytm so, uh, first to get his PR merged wins and loser has to clean up the conflict? |
@Emerentius yeah 😐 |
@kennytm I guess I win then 😛 |
4941579
to
ccb0166
Compare
This comment has been minimized.
This comment has been minimized.
ccb0166
to
bb0d05a
Compare
Ping from triage, @SimonSapin: This PR requires your review. |
I believe that #51622 (comment) is an unresolved issue. |
When the index is not PartialOrd, always treat the range as empty.
5e3bd09
to
dbfa8fe
Compare
@bors r=SimonSapin |
📌 Commit dbfa8fe2ca143818b94ded7b49e6511cfd4ff330 has been approved by |
This comment has been minimized.
This comment has been minimized.
dbfa8fe
to
6093128
Compare
📌 Commit 6093128 has been approved by |
⌛ Testing commit 6093128 with merge 00ebf67226780da280a20f4ec60d3c62adb9b58f... |
💔 Test failed - status-travis |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
1 similar comment
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
☀️ Test successful - status-appveyor, status-travis |
Fix #45222.
This PR also reverts #48012 (i.e. removed the
try_fold
/try_rfold
specialization forRangeInclusive
) because LLVM no longer has trouble recognizing a RangeInclusive loop.