Run loop modes are named by string, and as you can see in your link, comparisons of run loop modes are by their raw value--i.e. by string. While it's of course sensible to have a total ordering for strings, I'm skeptical that you would typically want to get the "maximum" of two strings, and I'm not aware of a use case for clamping a string to a range of strings.<br><br>If you're really doing that in your code, you should be aware that the default ordering for String (or was it just NSString?--my memory is hazy now) behaves differently on OS X and Linux, at least as of a few months ago. You really should be using string-specific comparison methods (either case-sensitive or not) on appropriately normalized strings, in my opinion.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 1, 2016 at 10:34 PM Karl <<a href="mailto:razielim@gmail.com">razielim@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On 31 Aug 2016, at 15:53, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br><div><div style="white-space:pre-wrap">Comparable makes semantic guarantees about how values of conforming types might be ordered. You don't need `min` or `max` for that to be useful, since it's trivial to implement using comparison operators.<br><br>Basic numeric types require compiler magic and thus belong in the standard library. Likewise, dictionaries have special syntactic sugar and have uses for types that can guarantee comparable semantics. A decimal type, though, can be implemented outside the standard library and probably would belong in a math library. Likewise mathematical constants such as e. I think min and max fall into the latter category.<br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 31, 2016 at 8:10 AM Karl <<a href="mailto:razielim@gmail.com" target="_blank">razielim@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On 30 Aug 2016, at 10:18, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> As an additive proposal, I don't think this would be in scope for the current phase of Swift 4.<br>
><br>
> Looking forward, though, I'm not sure this belongs in the standard library. In general, my understanding is that Swift's standard library is deliberately small, and that the criteria for additions are that it's widely used *and* also non-trivial for the user to write correctly. I've had to use clamping, obviously, but it's a trivial one-liner that is hard to write incorrectly. If anything, I'd be in favor of removing max and min into a future math library outside the standard library.<br>
<br>
min & max (and clamping) are hardly “math” operations. They operate on Comparables, so you can apply them to more abstract things than just numbers.<br>
<br>
Otherwise, you might as well put Comparable and all standard numeric types like Int and Float in a math library, too.</blockquote></div>
</div></blockquote></div><br></div><div style="word-wrap:break-word"><div>Concrete example I just happened to run across: Foundation’s RunLoopMode conforms to Comparable. It is entirely possible that you may get a collection of RunLoopModes and wish to find the min/max or clamp to a particular mode.</div><div><br></div><div><a href="https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSRunLoop.swift" target="_blank">https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSRunLoop.swift</a></div></div></blockquote></div>