On Thu, 03 Apr 2014 06:42:32 -0400, monarch_dodra <monarchdo...@gmail.com>
wrote:
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.
Then you shouldn't use opCmp.
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.
This can lead to false positives if opCmp(x, y) == 0 is assumed to mean
equal.
An example: if you used RBTree to store 2d points, and defined opCmp like
you did, then you wouldn't be able to store both (1, 0) and (0, 1) in the
same RBTree without duplicates.
-Steve
