-
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
Implement specialized nth_back()
for Zip
#68199
Conversation
r? @matthewjasper as per recent review of std specializations |
})) | ||
.nth_back(3); | ||
assert_eq!(value, Some((30, 4000))); | ||
assert_eq!(a, vec![6, 6, 5, 5, 4, 4, 3]); |
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.
This is not correct and appears to be a bug that exists in the current next_back
implementation. This should only contain each number once.
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.
Hm, so the current nth_back
implementation is also wrong?
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=ad07ad6a7077e2ba38eb232eed5e15bc
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.
It's calling next_back
, so yes.
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.
Filed it as #68536 (I think this PR encounters another roadblock that Niko pointed out, so left a new issue).
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.
I'm not entirely sure what we should do about this soundness problem; it seems like prioritizing work on specialization may be necessary to avoid reverting a lot of the existing specializations in the standard library.
@@ -142,6 +167,15 @@ where | |||
} | |||
} | |||
|
|||
#[inline] |
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.
Unfortunately, this specialization is unsound, though it's not a pre-existing problem, and not specific to this PR. See my comment here for a bit more context.
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.
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.
Maybe -- there are specific patterns that are sound -- but you have to specialize not based on traits but based on concrete types. e.g., specializing for vec::Iter
or something would be fine. But maybe there are so many types here that this is not practical?
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.
but you have to specialize not based on traits but based on concrete types. e.g., specializing for vec::Iter or something would be fine.
Yeah, it'd be an alternative. But unfortunately, I have no time to find alternative implementation. If I find some time, I'll re-open or submit another PR. Thanks for the review, Niko!
Rework of #60574 and part of #54054 (it can be closed by this?)
r? @scottmcm