[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

On Tue, Apr 25, 2017 at 3:12 AM, David Waite <david at alkaline-solutions.com>
wrote:

>
> On Apr 24, 2017, at 11:52 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Tue, Apr 25, 2017 at 12:45 AM, Jonathan Hull via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> +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.
>>
>
> Then it's an insoluble problem, because (and for good reasons) there are
> those who consider anything other than `.nan != .nan` to be a non-starter.
> My attempt to convince people that maybe we could just make that expression
> trap instead of giving an answer did not, evidently, win over too many
> fans. But I tend to sympathize with the numerics crowd that `.nan == .nan`
> would be disastrous for Swift when it comes to numerics. No other (common)
> language behaves that way.
>
>
> Java’s solution is to only support comparison operators for native types
> like floats and doubles, and to have the IEEE behavior for these types. The
> java.lang.Comparable interface does not expose operators, and thus does not
> have a naming conflict. The Comparable implementation for Float has strict
> total ordering, while ‘<‘ has IEEE behavior.
>
> So I think a sixth option I didn’t propose before. If we were pre Swift 3
> it would possibly be the more feasible one:
>
> 6. Do not define Equatable/Comparable in terms of the existing operators,
> and do not expose existing operators based on Equatable/Comparable.
> Instead, Equatable/Comparable define methods or new operators based on
> strict equality/total ordering.  Conformance to some other sub-protocol
> like StrictlyEquatable/StrictlyComparable is used to opt into exposing
> operators based on implementing strict equality and total ordering.
>

That's a neat idea. If Comparable only vended the spaceship, then there
would be no clash. Then you provide another protocol (which I think would
be nicely called Ordered, but StrictlyComparable is what you're calling it
here), which gives back operators like < but requires a total order. The
migration path would indeed be difficult.

This would mean that Equatable/Comparable generic algorithms are forced to
> always use total ordering algorithms without the chance of having a
> conflict with floating point operators - because the naming no longer
> conflicts.
>
> -DW
>
>
> > 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
>> <http://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
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170425/6cf3fa67/attachment.html>