> 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.
- Karl
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
