On Fri, 25 Jul 2014 21:38:33 +0100, Walter Bright
<newshou...@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/
