WAT: opCmp and opEquals woes

[Manu via Digitalmars-d]

On 26 July 2014 13:33, Manu <turkeyman at gmail.com> wrote:

> On 26 July 2014 06:38, Walter Bright via Digitalmars-d <
> digitalmars-d at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140726/ca4f2a6e/attachment.html>