On 7/24/2014 10:52 PM, Manu via Digitalmars-d wrote:
I don't really see how opCmp == 0 could be unreliable or unintended. It was deliberately written by the author, so definitely not unintended, and I can't imagine anybody would ever deliberately ignore the == 0 case when implementing an opCmp, or produce logic that works for less or greater, but fails for equal. <= and >= are expressed by opCmp, which imply that testing for equality definitely works as the user intended.
Yes, that's why it's hard to see that it would break existing code, unless that existing code had a bug in it that was worked around in some peculiar way.
In lieu of an opEquals, how can a deliberately implemented opCmp, which we know works in the == case (otherwise <= or >= wouldn't work either) ever be a worse choice than an implicitly generated opEquals?
Determining an ordering can sometimes be more expensive. It is, after all, asking for more information.
