[swift-evolution] [pitch] Comparison Reform

[Xiaodi Wu]

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.

> 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
>
> _______________________________________________
> 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/b1c8b091/attachment.html>