WAT: opCmp and opEquals woes

[Jonathan M Davis via Digitalmars-d]

On Thursday, 24 July 2014 at 01:37:01 UTC, deadalnix wrote:
> 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 ?

When it comes to equality and comparison, floating point values 
are mess that I would really hope no one would be looking to 
emulate with their own types. I grant you that they're a built in 
type, but they do not have clean semantics (particularly with 
regards to equality). IMHO, user-defined types should emulate 
integers with regards to how the comparison operators work. 
Allowing more nonsense like what FP does does not improve things.

- Jonathan M Davis