[swift-evolution] [pitch] Comparison Reform

[David Waite]

> 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 <mailto: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.

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 <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
> >> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/3d043bf2/attachment.html>