What does it mean for opCmp and opEquals to be consistent?

[monarch_dodra]

On Thursday, 3 April 2014 at 10:15:46 UTC, Jonathan M Davis wrote:
> _Any_ type which overloads both opEquals and opCmp and does not 
> make them
> match exactly is just plain broken.

I disagree:

> If a.opEquals(b) is true, then a.opCmp(b) must be 0.
> If a.opCmp(b) is non-zero, then a.opEquals(b) must be false.

Yes.

> If a.opEquals(b) is false, then a.opCmp(b) must be non-zero.
> If a.opCmp(b) is 0, then a.opEquals(b) must be true.

I disagree.

You could have types with full comparison, but only *partial 
ordering*, depending on the "norm" you used to define their 
weight.

A trivial example would be a 2D coordinate object, where opEquals 
is what you'd expect, and opCmp is some sort of norm (say, 
Euclidian).

In this context, (1, 0) and (0, 1) would not be equal, but they'd 
have the same "weight" in terms of ordering.

EG: They are not "equal", but they are "equivalent" (to quote C++ 
terminology)

Or for example, a "Person" object. You'd have strict equality. 
But for ordering, you'd use height.

So (John, 182cm) and (David, 182cm) would not be equal, but 
they'd be equivalent.

--------

A correctly implemented AA would use opCmp to store objects in 
each bucket in cases of hash collisions, but still use opEqual in 
case of equivalence.