On 26 July 2014 13:33, Manu <[email protected]> wrote: > On 26 July 2014 06:38, Walter Bright via Digitalmars-d < > [email protected]> 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.
