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.
