On 13.05.2017 16:17, H. S. Teoh via Digitalmars-d wrote:
> On Sat, May 13, 2017 at 01:21:12PM +0000, Fool via Digitalmars-d wrote:
>> On Saturday, 13 May 2017 at 12:53:33 UTC, Nicholas Wilson wrote:
> [...]
>>> 3) you can do that already. w.r.t sort you pass a predicate
>>> (defaulting to "less") for which ordering is assumed to exist, if it
>>> doesn't then you get a partition according to that predicate.
>>
>> Another misunderstanding. Currently, there is no means to express that
>> 'less' models a partial order vs. a linear order.
>
> Wrong.  Andrei specifically stated before that opCmp may model a partial
> order, i.e., returning 0 may indicate "not comparable" rather than
> "equal".  And this is why opEquals is necessary: to distinguish between
> "not comparable" and "equal".
>
>
> T
>

I can't seem to find the post you are referring to but IIRC it was immediately destroyed completely.

On Saturday, May 13, 2017 20:52:48 Timon Gehr via Digitalmars-d wrote:
> On 13.05.2017 16:17, H. S. Teoh via Digitalmars-d wrote:
> > On Sat, May 13, 2017 at 01:21:12PM +0000, Fool via Digitalmars-d wrote:
> >> On Saturday, 13 May 2017 at 12:53:33 UTC, Nicholas Wilson wrote:
> > [...]
> >
> >>> 3) you can do that already. w.r.t sort you pass a predicate (defaulting to "less") for which ordering is assumed to exist, if it doesn't then you get a partition according to that predicate.
> >>
> >> Another misunderstanding. Currently, there is no means to express that 'less' models a partial order vs. a linear order.
> >
> > Wrong.  Andrei specifically stated before that opCmp may model a partial order, i.e., returning 0 may indicate "not comparable" rather than "equal".  And this is why opEquals is necessary: to distinguish between "not comparable" and "equal".
> >
> >
> > T
>
> I can't seem to find the post you are referring to but IIRC it was immediately destroyed completely.

I remember that coming up and a number of us (most of us?) thinking that what Andrei was suggesting was a bad idea, but I don't recall if there was ever an agreement about it. I'm terrible at finding old threads though, so I don't know where the thread on that is either.

With opEquals and opCmp (and operator overloading in general) are designed, I wouldn't expect it to be reasonable for opCmp == 0 to be different from opEquals == true, and opCmp != 0 equal to opEquals == false. They're basically supposed to be model how it works with integers (though floating point values do muck with it a bit thanks to NaN).

- Jonathan M Davis

On Saturday, 13 May 2017 at 14:17:24 UTC, H. S. Teoh wrote:
> Andrei specifically stated before that opCmp may model a partial order, i.e., returning 0 may indicate "not comparable" rather than "equal".  And this is why opEquals is necessary: to distinguish between "not comparable" and "equal".

As others have pointed out, that seems wrong. However, returning float.nan does make a bit of sense. Given a nan return value, a <= b and a >= b will both be false.

On Saturday, 13 May 2017 at 18:52:48 UTC, Timon Gehr wrote:
>
> I can't seem to find the post you are referring to but IIRC it was immediately destroyed completely.

It was probably in this thread:

http://forum.dlang.org/post/dhrtitehdkcgnlmukufb@forum.dlang.org

And as one can see generic support for comparison relations is non-trivial.