> On Feb 23, 2017, at 2:33 PM, Karl Wagner <[email protected]> wrote:
>
>
>> On 23 Feb 2017, at 19:40, Max Moiseev <[email protected]> wrote:
>>
>> Conformance to Comparable is not required by anything in the standard
>> library. Besides, it is always possible to further constrain your own code
>> as in:
>>
>
> Besides FloatingPoint, you mean? Or Collection indexes? Quite a lot of stuff,
> actually.
>
>> func f<T : Number>(_ x: T) where T.Magnitude : Comparable {}
>>
>> I would argue that adding constraints without solid proof of them being
>> useful and necessary is not the right thing to do.
>> Also, sorting things by magnitude will require using a predicate-based
>> sorted() anyway, and that does not require Comparable.
>>
>> Max
>
> Yes, but the constraints in the standard library should also convey some
> meaning and be useful. What do we mean by a “magnitude” anyway? Won’t it be
> strange in practice that I can create a “magnitude” out of nothing but an
> arbitrary integer literal but can’t compare two values? Ultimately it looks
> like a deficiency in the design to me - either it’s a simple scalar,
> ExpressibleByIntegerLiteral and Comparable, or it’s something more complex
> and can’t be either.
>
> This is exactly the kind of flaw I’ve been working around with the current
> Strideable.Stride (i.e. current SignedNumber). If a type is
> ExpressibleByIntegerLiteral, you should be able to basically do all the
> things to it that you can do with an integer.
(replying to bolded part)
Not necessarily... Complex numbers can conform to `ExpressibleByIntegerLiteral`
but not `Comparable`. At least not in a generally-accepted way.
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
