Tracking issue for Ord::{min, max}

[kornelski]

It's seems inconsistent that floating-point types have a min method, but integer types don't.

And there's a standalone min() function that works with integer types, but it's not defined for floating-point types.

I don't have a strong preference for either style, but I'd prefer that at least one way of computing min/max was available for both floating point and integer types alike.

[Aatch]

@aturon thoughts? Seems like adding an inherent method to integer types is the easiest way forward here.

Note that there are partial_min and partial_max functions for types that only implement PartialOrd.

[aturon]

+1 for an inherent method. I think this is just an oversight.

[alexcrichton]

I believe @bluss commented to this effect already, but the idea here is that there is "one true min method" at cmp::min, but the floating point types use a slightly different algorithm (e.g. different guarantees about order and whatnot), hence they have their own methods.

I wouldn't be totally opposed to adding an inherent method, but we'd want to clearly document that it's just an alias to cmp::min

[nagisa]

-1 for an inherent (or any other, really) method. Float’s min and max are just bindings to libm f{min.max}{f,}, while cmp::partial_{min,max} have their own, sane if you will, semantics. Adding inherent methods for integral types will make many-ways-to-do-the-same problem worse.

[frewsxcv]

Ignoring the "many-ways-to-do-the-same problem" for a second, couldn't min and max just be generic 'provided methods' on the Ord trait?

[kornelski]

For me this is a practical problem, because changing type needlessly changes syntax.

let a = 1.0;
let b = 2.0;
let c = a.max(b); // c = std::cmp::max(a,b)

I can't change a = 1; b = 2 without rewriting the third line.

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.

[Mark-Simulacrum]

@rust-lang/libs: Looks like this needs some thought; I've nominated. Possibly interesting for libz blitz discussion, too, since it relates to number types in wider library set; for example serde_json::Number doesn't implement min/max inherently, but should it?

I think that the things that have been brought up are:

• Rewriting code to use integers when floats were used previously is made needlessly difficult because of this (Tracking issue for Ord::{min, max} #25663 (comment))
• Adds to the "many ways" to do this (Tracking issue for Ord::{min, max} #25663 (comment))
• Maybe we could just have these be provided by Ord by-default (Tracking issue for Ord::{min, max} #25663 (comment))

[aturon]

We discussed this in triage today, and the libs team is in favor of adding these methods to Ord

[Mark-Simulacrum]

[De-nominating]

[aturon]

We're pretty much committed to this.

@rfcbot fcp merge

[rfcbot]

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

• @BurntSushi
• @Kimundi
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler

No concerns currently listed.

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.

[rfcbot]

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