Skip to content

Conversation

timvermeulen
Copy link
Contributor

@timvermeulen timvermeulen commented Aug 31, 2019

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
Copy link
Contributor

r? @withoutboats

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

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

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

Thanks.

@bors
Copy link
Collaborator

bors commented Sep 8, 2019

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

@cuviper
Copy link
Member

cuviper commented Sep 10, 2019

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
Copy link
Contributor Author

@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
Copy link
Member

cuviper commented Sep 11, 2019

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
Copy link
Contributor Author

@cuviper Thanks, I added it.

@cuviper
Copy link
Member

cuviper commented Sep 14, 2019

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
Copy link
Contributor Author

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

@cuviper
Copy link
Member

cuviper commented Sep 20, 2019

Looks great, thanks!

@bors r+

@bors
Copy link
Collaborator

bors commented Sep 20, 2019

📌 Commit 7217591 has been approved by cuviper

@bors 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 added a commit to tmandry/rust that referenced this pull request Sep 20, 2019
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
Copy link
Collaborator

bors commented Sep 21, 2019

⌛ Testing commit 7217591 with merge 660b5c8cbf99ec24131ddefe0d667303b2bcb15a...

tmandry added a commit to tmandry/rust that referenced this pull request Sep 21, 2019
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
Copy link
Member

tmandry commented Sep 21, 2019

@bors retry rolled up

@bors
Copy link
Collaborator

bors commented Sep 21, 2019

⌛ Testing commit 7217591 with merge 5349e69...

bors added a commit that referenced this pull request Sep 21, 2019
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
Copy link
Collaborator

bors commented Sep 21, 2019

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 21, 2019
@bors bors merged commit 7217591 into rust-lang:master Sep 21, 2019
@bors bors mentioned this pull request Sep 21, 2019
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants