[swift-evolution] [pitch] Comparison Reform

[Jonathan Hull]

+1

What I am arguing for is #2.  We have two different expectations and we need to be explicit about which is being used.  Furthermore, I am arguing that if one of them is going to be the default (and use the ‘==‘ and ‘<‘ symbols), it needs to be the strict equality/total ordering version, since that is what every other Swift type is modeling, and IEEE is only applicable to floating point.



> On Apr 24, 2017, at 9:44 PM, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I still think this is a naming conflict more than anything else. 
> 
> The first expectation is that equatable and comparable provides strict equality and strict total ordering, and that those are exposed via operators. The other expectation is that floating point abides by the IEEE rules which have neither of these, and are exposed via operators.
> 
> Either:
> 1. the operators need to do different things in different contexts
> 2. we need different methods/operators to indicate these different concepts
> 3. Equatable and comparable need to be altered to no longer require strict equality and strict total ordering (and all generic algorithms based on equatable/comparable need to be checked that they still work)
> 4. floating point numbers need to explicitly not be equatable/comparable to prevent their usage in generic algorithms requiring strict behavior.
> 5. We break away from IEEE behavior and provide only strict equality and strict total ordering
> 
> (I tried to sort these roughly in order of feasibility)
> 
> Are there any other options?
> 
> -DW
> 
>> On Apr 24, 2017, at 9:50 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Mon Apr 24 2017, Xiaodi Wu <xiaodi.wu-AT-gmail.com> wrote:
>> 
>>> On Mon, Apr 24, 2017 at 9:06 PM, Jonathan Hull via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>> 
>>>> As I am thinking about it more, this means that for == and <
>>>> 
>>>> NaN == NaN
>>>> -0 == +0
>>>> +Inf < NaN
>>>> 
>>>> Since this would break from IEEE,
>>> 
>>> Yeah, as Steve mentioned, it's a huge deal to break from IEEE rules. 
>> 
>> Allow me to put it even more strongly: I consider reinventing how
>> floating point works to be a massive undertaking comparable to
>> supplanting the Unicode standard with something better.  I have no doubt
>> that it could be done by somebody, somewhere, someday, but it would be
>> easy to do something much worse than what IEEE has done, and getting it
>> right would occupy so much of this group's time that we couldn't hope to
>> accomplish anything else, if we even had the expertise—I know I don't!
>> Doing anything in this area that is not firmly rooted in existing
>> standards and practices is not an option I'm willing to pursue.
>> 
>> -- 
>> -Dave
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution