On Tue, Apr 25, 2017 at 3:12 AM, David Waite <da...@alkaline-solutions.com> wrote:
> > On Apr 24, 2017, at 11:52 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, Apr 25, 2017 at 12:45 AM, Jonathan Hull via swift-evolution < > swift-evolution@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@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@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@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@swift.org >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > swift-evolution@swift.org >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
