Add `cmp::{min_by, min_by_key, max_by, max_by_key}` by timvermeulen · Pull Request #64047 · rust-lang/rust

timvermeulen · 2019-08-31T21:16:17Z

This adds the following functions to core::cmp:

min_by
min_by_key
max_by
max_by_key

min_by and max_by are somewhat trivial to implement, but not entirely because min_by returns the first value in case the two are equal (and max_by the second). min and max can be implemented in terms of min_by and max_by, but not as easily the other way around.

To give an example of why I think these functions could be useful: the Iterator::{min_by, min_by_key, max_by, max_by_key} methods all currently hard-code the behavior mentioned above which is an ever so small duplication of logic. If we delegate them to cmp::{min_by, max_by} methods instead, we get the correct behavior for free. (edit: this is now included in the PR)

I added min_by_key / max_by_key for consistency's sake but I wouldn't mind removing them. I don't have a particular use case in mind for them, and min_by / max_by seem to be more useful.

Tracking issue: #64460

rust-highfive · 2019-08-31T21:16:20Z

r? @withoutboats

(rust_highfive has picked a reviewer for you, use r? to override)

JohnCSimon · 2019-09-07T16:57:39Z

Ping from triage
@timvermeulen
@withoutboats @cuviper Can you please review this?

Thanks.

bors · 2019-09-08T16:51:39Z

☔ The latest upstream changes (presumably #64281) made this pull request unmergeable. Please resolve the merge conflicts.

cuviper · 2019-09-10T19:26:39Z

To give an example of why I think these functions could be useful: the Iterator::{min_by, min_by_key, max_by, max_by_key} methods all currently hard-code the behavior mentioned above which is an ever so small duplication of logic. If we delegate them to cmp::{min_by, max_by} methods instead, we get the correct behavior for free.

Did you try making this change?

timvermeulen · 2019-09-10T23:57:51Z

@cuviper I did indeed, here's the diff: timvermeulen@aed2e46

It's not a huge win, but it gets rid of the stability logic. And I guess it's also nice to have them in terms of the more general fold1 rather than select_fold1.

cuviper · 2019-09-11T21:56:58Z

I like it! Care to add that motivation to this PR?

Fill in a tracking issue too, and I think we can land this.

timvermeulen · 2019-09-14T17:31:34Z

@cuviper Thanks, I added it.

cuviper · 2019-09-14T18:28:35Z

I meant to actually include the iterator commit here, but it can be a followup if you prefer.

The tracking issue number needs to be set in the #[unstable] attributes.

timvermeulen · 2019-09-14T18:56:20Z

Ah, I was going to submit a follow-up, but I'm happy to include it here too.

cuviper · 2019-09-20T23:24:33Z

Looks great, thanks!

@bors r+

bors · 2019-09-20T23:24:34Z

📌 Commit 7217591 has been approved by cuviper

Add `cmp::{min_by, min_by_key, max_by, max_by_key}` This adds the following functions to `core::cmp`: - `min_by` - `min_by_key` - `max_by` - `max_by_key` `min_by` and `max_by` are somewhat trivial to implement, but not entirely because `min_by` returns the first value in case the two are equal (and `max_by` the second). `min` and `max` can be implemented in terms of `min_by` and `max_by`, but not as easily the other way around. To give an example of why I think these functions could be useful: the `Iterator::{min_by, min_by_key, max_by, max_by_key}` methods all currently hard-code the behavior mentioned above which is an ever so small duplication of logic. If we delegate them to `cmp::{min_by, max_by}` methods instead, we get the correct behavior for free. (edit: this is now included in the PR) I added `min_by_key` / `max_by_key` for consistency's sake but I wouldn't mind removing them. I don't have a particular use case in mind for them, and `min_by` / `max_by` seem to be more useful. Tracking issue: rust-lang#64460

bors · 2019-09-21T01:13:25Z

⌛ Testing commit 7217591 with merge 660b5c8cbf99ec24131ddefe0d667303b2bcb15a...

Add `cmp::{min_by, min_by_key, max_by, max_by_key}` This adds the following functions to `core::cmp`: - `min_by` - `min_by_key` - `max_by` - `max_by_key` `min_by` and `max_by` are somewhat trivial to implement, but not entirely because `min_by` returns the first value in case the two are equal (and `max_by` the second). `min` and `max` can be implemented in terms of `min_by` and `max_by`, but not as easily the other way around. To give an example of why I think these functions could be useful: the `Iterator::{min_by, min_by_key, max_by, max_by_key}` methods all currently hard-code the behavior mentioned above which is an ever so small duplication of logic. If we delegate them to `cmp::{min_by, max_by}` methods instead, we get the correct behavior for free. (edit: this is now included in the PR) I added `min_by_key` / `max_by_key` for consistency's sake but I wouldn't mind removing them. I don't have a particular use case in mind for them, and `min_by` / `max_by` seem to be more useful. Tracking issue: rust-lang#64460

tmandry · 2019-09-21T01:20:46Z

@bors retry rolled up

bors · 2019-09-21T04:21:33Z

⌛ Testing commit 7217591 with merge 5349e69...

Add `cmp::{min_by, min_by_key, max_by, max_by_key}` This adds the following functions to `core::cmp`: - `min_by` - `min_by_key` - `max_by` - `max_by_key` `min_by` and `max_by` are somewhat trivial to implement, but not entirely because `min_by` returns the first value in case the two are equal (and `max_by` the second). `min` and `max` can be implemented in terms of `min_by` and `max_by`, but not as easily the other way around. To give an example of why I think these functions could be useful: the `Iterator::{min_by, min_by_key, max_by, max_by_key}` methods all currently hard-code the behavior mentioned above which is an ever so small duplication of logic. If we delegate them to `cmp::{min_by, max_by}` methods instead, we get the correct behavior for free. (edit: this is now included in the PR) I added `min_by_key` / `max_by_key` for consistency's sake but I wouldn't mind removing them. I don't have a particular use case in mind for them, and `min_by` / `max_by` seem to be more useful. Tracking issue: #64460

bors · 2019-09-21T08:10:58Z

☀️ Test successful - checks-azure
Approved by: cuviper
Pushing 5349e69 to master...

rust-highfive assigned withoutboats Aug 31, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 31, 2019

timvermeulen mentioned this pull request Sep 14, 2019
Tracking issue for cmp::{min_by, min_by_key, max_by, max_by_key}#64460
Closed

timvermeulen added 2 commits September 14, 2019 21:52

Add cmp::{min_by, min_by_key, max_by, max_by_key}
6e5ada4

Simplify Iterator::{min_by, max_by} using cmp::{min_by, max_by}
7217591

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 20, 2019

tmandry mentioned this pull request Sep 20, 2019
Rollup of 10 pull requests #64646
Closed

tmandry mentioned this pull request Sep 21, 2019
Rollup of 10 pull requests #64647
Closed

bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 21, 2019

bors merged commit 7217591 into rust-lang:masterSep 21, 2019

bors mentioned this pull request Sep 21, 2019
Add by-value iterator for arrays #62959
Merged
5 tasks

emilio mentioned this pull request Sep 23, 2019
cmp::max changed behavior in nightly #64710
Closed

Uh oh!

Uh oh!

Conversation

timvermeulen commented Aug 31, 2019• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Aug 31, 2019

Uh oh!

JohnCSimon commented Sep 7, 2019

Uh oh!

bors commented Sep 8, 2019

Uh oh!

cuviper commented Sep 10, 2019

Uh oh!

timvermeulen commented Sep 10, 2019

Uh oh!

cuviper commented Sep 11, 2019

Uh oh!

timvermeulen commented Sep 14, 2019

Uh oh!

cuviper commented Sep 14, 2019

Uh oh!

timvermeulen commented Sep 14, 2019

Uh oh!

cuviper commented Sep 20, 2019

Uh oh!

bors commented Sep 20, 2019

Uh oh!

bors commented Sep 21, 2019

Uh oh!

tmandry commented Sep 21, 2019

Uh oh!

bors commented Sep 21, 2019

Uh oh!

bors commented Sep 21, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

timvermeulen commented Aug 31, 2019•
edited
Loading