On 01/12/2016 06:52 PM, John Colvin wrote:
> On Tuesday, 12 January 2016 at 22:28:13 UTC, Andrei Alexandrescu wrote:
>> On 01/12/2016 03:56 PM, John Colvin wrote:
>>> Please consider the second design I proposed?
>>
>> I don't think it solves a large problem. -- Andrei
>
> Ok. Would you consider any solution, or is that a "leave it broken"?

I'd leave it to a named function. Using the built-in comparison for exotic orderings is bound to confuse users. BTW not sure you know, but D used to have a number of floating point operators like !<>=. Even those didn't help. -- Andrei

On Wednesday, 13 January 2016 at 00:31:48 UTC, Andrei Alexandrescu wrote:
> I'd leave it to a named function. Using the built-in comparison for exotic orderings is bound to confuse users. BTW not sure you know, but D used to have a number of floating point operators like !<>=. Even those didn't help. -- Andrei

Although I would have use for "exotic orderings" in some of my own code, I think this is the right decision.

Really the only reason I'm tempted to say they should be allowed, is to smooth interaction with floating-point. But, I think what that really means is that the design of the floating-point comparisons is bad. (Which is not D's fault, I know.)

On Wednesday, 13 January 2016 at 00:31:48 UTC, Andrei Alexandrescu wrote:
> On 01/12/2016 06:52 PM, John Colvin wrote:
>> On Tuesday, 12 January 2016 at 22:28:13 UTC, Andrei Alexandrescu wrote:
>>> On 01/12/2016 03:56 PM, John Colvin wrote:
>>>> Please consider the second design I proposed?
>>>
>>> I don't think it solves a large problem. -- Andrei
>>
>> Ok. Would you consider any solution, or is that a "leave it broken"?
>
> I'd leave it to a named function. Using the built-in comparison for exotic orderings is bound to confuse users. BTW not sure you know, but D used to have a number of floating point operators like !<>=. Even those didn't help. -- Andrei

I would completely agree, except that we have builtin types that don't obey this rule. I'd be all in favour of sticking with total orders, but it does make it hard (impossible?) to make a proper drop-in replacement for the builtin floating point numbers (including wrappers, e.g. std.typecons.Typedef can't handle nans correctly) or to properly handle comparisons between custom types and builtin floating points (as mentioned by tsbockman).

I am all for keeping it simple here, but I still think there's a problem.

On Wednesday, 13 January 2016 at 01:39:26 UTC, John Colvin wrote:
> On Wednesday, 13 January 2016 at 00:31:48 UTC, Andrei Alexandrescu wrote:
>> [...]
>
> I would completely agree, except that we have builtin types that don't obey this rule. I'd be all in favour of sticking with total orders, but it does make it hard (impossible?) to make a proper drop-in replacement for the builtin floating point numbers (including wrappers, e.g. std.typecons.Typedef can't handle nans correctly) or to properly handle comparisons between custom types and builtin floating points (as mentioned by tsbockman).
>
> I am all for keeping it simple here, but I still think there's a problem.

https://issues.dlang.org/show_bug.cgi?id=15561

On Wednesday, 13 January 2016 at 01:43:21 UTC, John Colvin wrote:
>> I am all for keeping it simple here, but I still think there's a problem.
>
> https://issues.dlang.org/show_bug.cgi?id=15561

That's a good point.

On Wednesday, 13 January 2016 at 02:12:36 UTC, tsbockman wrote:
> On Wednesday, 13 January 2016 at 01:43:21 UTC, John Colvin wrote:
>>> I am all for keeping it simple here, but I still think there's a problem.
>>
>> https://issues.dlang.org/show_bug.cgi?id=15561
>
> That's a good point.

Interesting. I often use partially-ordered objects in my code, and therefore define opCmp to return float, making use of the NaN value. But then I also define opEquals to return false for (NaN == NaN), and my custom types work as intended.
In fact, the existance of the special floatingpoint operators like !<> (and beeing able to overload them) was one of the main reasons for me, to start using D. For me it's a mayor issue if those operators don't work correct.

I know they are deprecated, but I don't know why. As was pointed out they are necessary if you want to implement something partially ordered. That not everybody needs this is no valid reason to deprecate it.

I hated to be told I should not define opCmp to return float instead of int, as was also propagated by the "learning D" book.
If this is the common state of the art, I will drop D and start using my own fork the moment they are not supported anymore.

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)

On Wednesday, 13 January 2016 at 01:43:21 UTC, John Colvin wrote:
> On Wednesday, 13 January 2016 at 01:39:26 UTC, John Colvin wrote:
>> On Wednesday, 13 January 2016 at 00:31:48 UTC, Andrei Alexandrescu wrote:
>>> [...]
>>
>> I would completely agree, except that we have builtin types that don't obey this rule. I'd be all in favour of sticking with total orders, but it does make it hard (impossible?) to make a proper drop-in replacement for the builtin floating point numbers (including wrappers, e.g. std.typecons.Typedef can't handle nans correctly) or to properly handle comparisons between custom types and builtin floating points (as mentioned by tsbockman).
>>
>> I am all for keeping it simple here, but I still think there's a problem.
>
> https://issues.dlang.org/show_bug.cgi?id=15561

https://github.com/D-Programming-Language/phobos/pull/3927