On 26 July 2014 13:33, Manu <turkeyman@gmail.com> wrote:
On 26 July 2014 06:38, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
On 7/25/2014 4:10 AM, Regan Heath wrote:
Sure, Andrei makes a valid point .. for a minority of cases.  The majority case
will be that opEquals and opCmp==0 will agree.  In those minority cases where
they are intended to disagree the user will have intentionally defined both, to
be different.  I cannot think of any case where a user will intend for these to
be different, then not define both to ensure it.

You've agreed with my point, then, that autogenerating opEquals as memberwise equality (not opCmp==0) if one is not supplied will be correct unless the user code is already broken.

No, because there's no obvious reason to define opEquals if you do define opCmp, and the opEq

Oops, sorry! Hit the send hotkey >_<

No, because there's no obvious reason to define opEquals if you do define opCmp and the opEquals would be the same.
It seems to me, at face value, that opCmp is for full range of comparisons, and opEquals is for unordered types. Surely this is a reasonable conclusion to make?

I don't see how you can say that a compiler generated opEquals in the presence of a user opCmp can reliably be correct.
It may be correct, if you're lucky, and that's the best offer you'll get.
opCmp==0 however is practically certain to be correct, since <= and >= are required to work... and the api embodies the concept of equality, it would be very hard to write an implementation where equal was broken, but <,<=,>=,> all worked.