Closed
Description
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.
Metadata
Metadata
Assignees
Labels
Blocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCRelevant to the library API team, which will review and decide on the PR/issue.In the final comment period and will be merged soon unless new substantive objections are raised.
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
Aatch commentedon May 21, 2015
@aturon thoughts? Seems like adding an inherent method to integer types is the easiest way forward here.
Note that there are
partial_min
andpartial_max
functions for types that only implementPartialOrd
.aturon commentedon May 21, 2015
+1 for an inherent method. I think this is just an oversight.
alexcrichton commentedon May 26, 2015
I believe @bluss commented to this effect already, but the idea here is that there is "one true
min
method" atcmp::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 commentedon Jun 17, 2015
-1 for an inherent (or any other, really) method. Float’s min and max are just bindings to libm
f{min.max}{f,}
, whilecmp::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 commentedon Dec 14, 2016
Ignoring the "many-ways-to-do-the-same problem" for a second, couldn't
min
andmax
just be generic 'provided methods' on theOrd
trait?kornelski commentedon Dec 14, 2016
For me this is a practical problem, because changing type needlessly changes syntax.
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 commentedon May 18, 2017
@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:
aturon commentedon May 23, 2017
We discussed this in triage today, and the libs team is in favor of adding these methods to
Ord
Mark-Simulacrum commentedon May 23, 2017
[De-nominating]
10 remaining items
rfcbot commentedon Aug 29, 2017
Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams:
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 commentedon Sep 12, 2017
🔔 This is now entering its final comment period, as per the review above. 🔔
Rollup merge of rust-lang#44593 - budziq:stabilize_ord_max_min, r=ale…
Rollup merge of rust-lang#44593 - budziq:stabilize_ord_max_min, r=ale…
Rollup merge of rust-lang#44593 - budziq:stabilize_ord_max_min, r=ale…
stabilized ord_max_min (fixes rust-lang#25663)