Tracking issue for Ord::{min, max}

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.

@aturon

@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.

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

@bluss

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

-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.

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?

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.

@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))

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

[De-nominating]

Rollup merge of rust-lang#42496 - Razaekel:feature/integer_max-min, r…

stabilized ord_max_min (fixes rust-lang#25663)

Rollup merge of rust-lang#44593 - budziq:stabilize_ord_max_min, r=ale…

stabilized ord_max_min (fixes rust-lang#25663)

Auto merge of #161081 - scottmcm:min-max-intrinsics, r=clarfonthey

Navigation Menu

Repository navigation

Tracking issue for Ord::{min, max} #25663

13 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for Ord::{min, max} #25663

Description

Activity

Aatch commented on May 21, 2015

aturon commented on May 21, 2015

alexcrichton commented on May 26, 2015

nagisa commented on Jun 17, 2015

frewsxcv commented on Dec 14, 2016

kornelski commented on Dec 14, 2016

Mark-Simulacrum commented on May 18, 2017

aturon commented on May 23, 2017

Mark-Simulacrum commented on May 23, 2017

13 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions