opCmp, [partial/total/pre]orders, custom floating point types etc.

[John Colvin via Digitalmars-d]

On Tuesday, 12 January 2016 at 21:27:38 UTC, Timon Gehr wrote:
> On 01/12/2016 10:02 PM, John Colvin wrote:
>> On Tuesday, 12 January 2016 at 20:52:51 UTC, Timon Gehr wrote:
>>> On 01/12/2016 07:27 PM, John Colvin wrote:
>>>> ...
>>>
>>>
>>> struct S{
>>>     auto opCmp(S rhs){ return float.nan; }
>>>     bool opEquals(S rhs){ return false; }
>>> }
>>>
>>> unittest{
>>>     S a,b;
>>>     assert(!(a==b));
>>>     assert(!(a<b));
>>>     assert(!(a<=b));
>>>     assert(!(a>b));
>>>     assert(!(a>=b));
>>> }
>>
>> what about classes and Object.opCmp?
>
> You can introduce a new opCmp signature in your subclass, but 
> == is enforced to be reflexive for class objects. So this 
> approach only really works for structs. (And for structs, it is 
> obviously a hack.)

I actually quite like it. Also, checking the generated assembly 
for an IntWithNaN type: no floating point comparisons in sight 
(with gdc and ldc at least, don't really care if dmd does 
something a bit dumb)