Fixing opEquals and opCmp

[Fool via Digitalmars-d]

On Saturday, 13 May 2017 at 12:53:33 UTC, Nicholas Wilson wrote:
> For most types equality exists (i.e. are all members equal?), 
> but ordering is nonsensical.

How does this relate to what I wrote?

If you want to support equality only, implement opCmp with return 
type Equality. (In Herb's proposal uses the spaceship operator 
<=> instead of opCmp and strong_equality for Equality.)


> to answer your why questions:
> 1) see above, we're still doing better than C++ (although in 
> the contexts of DLSs individual operator overloading is useful.

It's not about C++, it's about D.

If Herb's proposal is accepted (after being corrected) then - 
indeed - C++ will be doing better than D. ;-)


> 2) see 1. you need only define both if opEquals is a 
> requirement for performance. defining opCmp suffices for 
> (in)equality. and you don't define opCmp unless your type has 
> sensible ordering.

What I was saying is: defining opCmp implies a definition of 
equivalence which now needs to be specified redundantly in 
opEquals. The developer now is responsible to ensure consistency 
between opCmp and opEquals.


> 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.