[swift-evolution] [Idea] Add `bounds` function to standard library

Xiaodi Wu xiaodi.wu at gmail.com
Thu Sep 1 23:14:56 CDT 2016

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.

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.

On Thu, Sep 1, 2016 at 10:34 PM Karl <razielim at gmail.com> wrote:

> On 31 Aug 2016, at 15:53, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 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.
> 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.
> On Wed, Aug 31, 2016 at 8:10 AM Karl <razielim at gmail.com> wrote:
>> > On 30 Aug 2016, at 10:18, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> > As an additive proposal, I don't think this would be in scope for the
>> current phase of Swift 4.
>> >
>> > 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.
>> min & max (and clamping) are hardly “math” operations. They operate on
>> Comparables, so you can apply them to more abstract things than just
>> numbers.
>> Otherwise, you might as well put Comparable and all standard numeric
>> types like Int and Float in a math library, too.
> 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.
> https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSRunLoop.swift
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160902/bed89405/attachment.html>

More information about the swift-evolution mailing list