WAT: opCmp and opEquals woes

[H. S. Teoh via Digitalmars-d]

On Fri, Jul 25, 2014 at 12:10:31PM +0100, Regan Heath via Digitalmars-d wrote:
> On Fri, 25 Jul 2014 09:39:11 +0100, Walter Bright
> <newshound2 at digitalmars.com> wrote:
> 
> >On 7/25/2014 1:02 AM, Jacob Carlborg wrote:
> >>3. If opCmp is defined but no opEquals, lhs == rhs will be lowered
> >>to lhs.opCmp(rhs) == 0
> >
> >This is the sticking point. opCmp and opEquals are separate on
> >purpose, see Andrei's posts.
> 
> 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.
[...]

Exactly!! I don't understand why people keep bringing up non-linear
partial orderings -- those only apply in a *minority* of cases! (Raise
your hands if your code depends on non-linear partial orderings. How
many of you *require* this more often than linear orderings? Yeah, I
thought so.) Why are we sacrificing *common* case -- where opCmp defines
a linear ordering -- for the minority case?

And it's not like we're making it impossible in the minority case -- if
you want a non-linear partial ordering, wouldn't you make sure to define
both opCmp and opEquals so that they do the right thing? Since it's an
uncommon use case, people would tend to be more careful when
implementing it. I argue that it's in the *common* case of linear
orderings, where people are more liable to assume (incorrectly, it
seems!) that opEquals should default to opCmp()==0 -- and that's the
case we should be addressing. Let's not lose sight of the forest for the
minority of the trees.


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.