WAT: opCmp and opEquals woes

[Regan Heath via Digitalmars-d]

On Fri, 25 Jul 2014 21:38:33 +0100, Walter Bright  
<newshound2 at digitalmars.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, you've miss-understood my point.

My point was that for the vast majority of coders, in the vast majority of  
cases opCmp()==0 will agree with opEquals().  It is only in very niche  
cases i.e. where partial ordering is actually present and important, that  
this assumption should be broken.

Yet, by default, if a user defines opCmp() the compiler generated opEquals  
may well violate that assumption.  This is surprising and will lead to  
subtle bugs.

If someone is intentionally defining an object for partial ordering they  
will expect to have to define both opCmp and opEquals, and not only that,  
if they somehow neglect to do so their first test of partial ordering will  
show they have a bug and they will soon realise their mistake.

The same cannot be said for someone who wants total ordering (the majority  
of users in the majority of cases).  In this case they are unlikely to  
specifically test for ordering bugs, and this mistake will creep in cause  
trouble down the line.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/