Fixing opEquals and opCmp

[Jonathan M Davis via Digitalmars-d]

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