WAT: opCmp and opEquals woes

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 23 July 2014 at 21:36:16 UTC, Andrei Alexandrescu 
wrote:
> On 7/23/14, 12:04 PM, H. S. Teoh via Digitalmars-d wrote:
>> If autogenerating opEquals to be opCmp()==0 is a no-go, then 
>> I'd much
>> rather say it should be a compile error if the user defines 
>> opCmp but
>> not opEquals.
>
> No. There is this notion of partial ordering that makes objects 
> not smaller and not greater than others, yet not equal. --

I would strongly argue that if lhs.opCmp(rhs) == 0 is not 
equivalent to lhs == rhs, then it that type is broken and should 
not be using opCmp to do its comparisons. std.algorithm.sort 
allows you to use any predicate you want, allowing for such 
orderings, but it does not work with generic code for a type to 
define opCmp or opEquals such that they're not consistent, 
because that's not consistent with how comparisons work for the 
built-in types.

- Jonathan M Davis