WAT: opCmp and opEquals woes

[deadalnix via Digitalmars-d]

On Thursday, 24 July 2014 at 00:28:06 UTC, Jonathan M Davis wrote:
> 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

floating point ?