> On Feb 24, 2017, at 4:45 PM, Xiaodi Wu <[email protected]> wrote:
>
> That was a deliberate design choice discussed during review of floating point
> protocols. Floating point remainder and integer modulo are very different.
> Spelling them the same way enables use in generic protocols, which would be
> incorrect uses. This was borne out by observation of erroneous uses of
> floating point % in Swift 2.
> On Fri, Feb 24, 2017 at 18:13 David Sweeris via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
> On Feb 23, 2017, at 14:44, David Sweeris <[email protected]
> <mailto:[email protected]>> wrote:
>
>>
>>> On Feb 23, 2017, at 2:33 PM, Karl Wagner <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>
>>>> On 23 Feb 2017, at 19:40, Max Moiseev <[email protected]
>>>> <mailto:[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.
>
> Perhaps a better example would be the `%` operator, since it involves stdlib
> types. Floating point types are ExpressibleByIntegerLiteral, but don't have
> the % operator that integers have.
Oh, I know. I was just pointing out another instance where a type conforms to
`ExpressibleByIntegerLiteral` and can’t do something Int can do.
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
