Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

JohnTitor
Copy link
Member

Rework of #60574 and part of #54054 (it can be closed by this?)

r? @scottmcm

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 14, 2020
@Mark-Simulacrum
Copy link
Member

r? @matthewjasper as per recent review of std specializations
cc @nikomatsakis

}))
.nth_back(3);
assert_eq!(value, Some((30, 4000)));
assert_eq!(a, vec![6, 6, 5, 5, 4, 4, 3]);
Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

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.

Copy link
Member Author

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).

Copy link
Contributor

@nikomatsakis nikomatsakis left a 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]
Copy link
Contributor

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, so I think we should stop the work for #54054 until the problem(#67194) is resolved, right?

Copy link
Contributor

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?

Copy link
Member Author

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!

@JohnTitor JohnTitor closed this Feb 1, 2020
@JohnTitor JohnTitor deleted the nth-back-zip branch March 27, 2020 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants