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

Tracking issue for the cmp::Reverse type #40893

Closed
mitsuhiko opened this issue Mar 29, 2017 · 13 comments
Closed

Tracking issue for the cmp::Reverse type #40893

mitsuhiko opened this issue Mar 29, 2017 · 13 comments
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@mitsuhiko
Copy link
Contributor

Added in #40720 under the reverse_cmp_key feature flag.

@BurntSushi BurntSushi added B-unstable Blocker: Implemented in the nightly compiler and unstable. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Mar 29, 2017
@alexcrichton
Copy link
Member

@rfcbot fcp merge

Seems like a nifty feature to stabilize!

@rfcbot
Copy link

rfcbot commented May 11, 2017

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged teams:

Concerns:

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@dtolnay
Copy link
Member

dtolnay commented May 11, 2017

I think a wrapper type makes sense by analogy with std::num::Wrapping. 👍

Elsewhere in std we call this "rev" instead of "reverse". 👎

I see the iter module mentioned in the PR but not the Rev type so it doesn't seem like this was discussed. Does it make more sense to call this std::cmp::Rev?

@rfcbot concern rev

@BurntSushi
Copy link
Member

@dtolnay Slices have a reverse method. :-)

@dtolnay
Copy link
Member

dtolnay commented May 11, 2017

Well shucks.

Comparing by conceptual similarity, I think this feature has more in common with std::iter::Rev than with slice reverse. They mean "don't do anything, but the next thing I ask you to do, do it backwards."

FWIW I think Reverse is a better name.

@BurntSushi
Copy link
Member

FWIW I think Reverse is a better name.

Me too. Given we already have the inconsistency, I think that pushes me toward Reverse.

@dtolnay
Copy link
Member

dtolnay commented May 12, 2017

With a clean slate, would we call them Iterator::reverse and std::iter::Reverse?

  • If so, is there somewhere we should be tracking this so that when the AI overlords invent a way to version std, they can follow up?
  • If not, is there any way to rationalize the difference?

@alexcrichton
Copy link
Member

I feel like we discussed Iterator::rev vs Iterator::reverse a long time ago, but that was like pre-1.0 days. I always find it hard to drag up these rationales after-the-fact. (e.g. why std::iter and not std::iterator?)

@mitsuhiko
Copy link
Contributor Author

FWIW the Python model has traditionally been "short names for modules" and "long descriptive names for methods" which is also what seems to be followed generally in Rust now. It does feel like rev() is one of the few exceptions to that rule.

@dtolnay
Copy link
Member

dtolnay commented May 17, 2017

Reverse is a better name.

@rfcbot resolved rev

@rfcbot
Copy link

rfcbot commented May 23, 2017

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label May 23, 2017
@scottmcm
Copy link
Member

There's also the Ordering::reverse method, so the struct version of that being Reverse seems logical 👍

@rfcbot
Copy link

rfcbot commented Jun 2, 2017

The final comment period is now complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants