Add max and min to Ord

[Razaekel]

Pursuant to issue #25663, this PR adds max and min methods with default implementations to std::cmp::Ord. It also modifies std::cmp::max|min to internally alias to Ord::max|min, so that any overrides of the default implementations are automatically used by std::cmp::max|min.

Closes #25663

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @aturon (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[Mark-Simulacrum]

Not sure if this is the best place to discuss this, but I think both of these could take (&self, other: &Self) and allow us to relax the Self: Sized bound -- getting an ordering doesn't require by-value access.

[Razaekel]

I chose to use by-value access because that's the same as what the std::cmp::max|min code below this does, and this PR is essentially moving those fns into Ord.

Plus, this isn't getting an Ordering the way cmp above is, but moving/copying both values in, comparing them, and then returning one. I think if I took (&self, other: &Self), I'd have to return a &Self, which would violate the API defined by std::cmp::max|min.

[Mark-Simulacrum]

I think it makes sense to keep them for now, but wanted to bring it up since maybe others will want to change it "while we're at it."

[Razaekel]

I don't have an issue with it either way, I was just keeping things similar to what already existed since that results in less surprises.

[scottmcm]

I agree that T is a more helpful return type than &T.

Also, #25663 (comment) argues for consistency with the inherent impl on fN:

I often write performance-sensitive graphics code, which I prototype on floats for ease of writing, and then where appropriate change to use integers for speed/memory efficiency. 90% of calculations just work, and max is one of the warts that doesn't.

Shame that a.min(&b) fails to compile instead of auto-deref'ing to (&a).min(&b), as it'd be an elegant way to use the impl<T:Ord> Ord for &T where borrow comparison is desirable...

[carols10cents]

Aturon's on vacation this week, sorry this fell through the cracks last week! Let's try...

r? @BurntSushi

[BurntSushi]

LGTM! Thank you! @bors r+

[bors]

📌 Commit a32ffc6 has been approved by BurntSushi

[bors]

⌛️ Testing commit a32ffc6 with merge 378887b...

[bors]

💔 Test failed - status-travis

[Mark-Simulacrum]

@bors retry

• os x timeouts

[bors]

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

[arielb1]

This had causes quite a few regressions in code. Do we still want this in this form?

[BurntSushi]

Is there a tracking issue for these regressions? There do seem to be a fair number of them. cc @rust-lang/libs

[aturon]

@BurntSushi I don't know of any tracking issue for regressions. Looks like there are 7 linking to this issue, with only 2 still open. I consider this an acceptable count, given that this was permissible breakage.

[alexcrichton]

This did I think cause more regressions than we thought was going to happen. In that sense I wouldn't be opposed if it was proposed to be reverted, but I also don't think I'd advocate for reverting this.