+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 > <[email protected]> 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 >> <[email protected]> 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 < >>> [email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
