Is there any interest in fixing opEquals and opCmp in the spirit(*) of [1]?

Translating the basic idea into the D world would mean:
 - Drop opEquals
 - Encode the type of comparison in the return type of opCmp
 - Adapt lowering

Why?
 - Simplicity: there is always only one function that needs to be implemented;
 - Consistency: implementation at a single place makes it more difficult to get it wrong;
 - Expressivity: through the return type implementors can unambiguously specify the properties of comparison relations (Equivalence, Equality, PartialOrdering, LinearOrdering, etc.) and algorithms can more precisely specify their requirements (e.g. general sorting requires a weak ordering whereas topological sorting requires a preorder, only);

[1] Herb Sutter: Consistent comparison, P0515 R0, 2017-02-05
    URL http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0515r0.pdf

(*) Some aspects of the proposal are unsound but those can be easily fixed.

On Saturday, 13 May 2017 at 12:11:49 UTC, Fool wrote:
> Is there any interest in fixing opEquals and opCmp in the spirit(*) of [1]?
>
> Translating the basic idea into the D world would mean:
>  - Drop opEquals
>  - Encode the type of comparison in the return type of opCmp
>  - Adapt lowering
>
> Why?
>  - Simplicity: there is always only one function that needs to be implemented;
>  - Consistency: implementation at a single place makes it more difficult to get it wrong;
>  - Expressivity: through the return type implementors can unambiguously specify the properties of comparison relations (Equivalence, Equality, PartialOrdering, LinearOrdering, etc.) and algorithms can more precisely specify their requirements (e.g. general sorting requires a weak ordering whereas topological sorting requires a preorder, only);
>
> [1] Herb Sutter: Consistent comparison, P0515 R0, 2017-02-05
>     URL http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0515r0.pdf
>
> (*) Some aspects of the proposal are unsound but those can be easily fixed.

For most types equality exists (i.e. are all members equal?), but ordering is nonsensical.

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

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.

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

-- 
A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth

On Saturday, 13 May 2017 at 14:17:24 UTC, H. S. Teoh wrote:
>> 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".

How is this reflected in the interface?

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

Well, that's unsound.

Example: 'is (proper) subset of'

Given the sets a:= {1} and b:= {2}, we have

 a is not a proper subset of b;
 b is not a proper subset of a;

If a.opCmp(b) returns 0 in this situation then, due to the rewrite

 a <= b   a.opCmp(b) <= 0,

we have:

 a is a subset of b

On Saturday, 13 May 2017 at 15:00:27 UTC, Fool wrote:
> 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".
>
> Well, that's unsound.
>
> Example: 'is (proper) subset of'
>
> Given the sets a:= {1} and b:= {2}, we have
>
>  a is not a proper subset of b;
>  b is not a proper subset of a;
>
> If a.opCmp(b) returns 0 in this situation then, due to the rewrite
>
>  a <= b   a.opCmp(b) <= 0,
>
> we have:
>
>  a is a subset of b

In this case, typeof(a) should not be the same as typeof(b), which can be handled correctly by opCmp.

On Saturday, 13 May 2017 at 15:05:02 UTC, Stanislav Blinov wrote:
> In this case, typeof(a) should not be the same as typeof(b), which can be handled correctly by opCmp.

Now you are trolling me. ;-)

Obviously a and b share the same type. They are sets.

I apologize for even thinking about the possibility that something could be wrong and might require a fix.

Have a good time!

On Saturday, 13 May 2017 at 15:31:40 UTC, Fool wrote:
> I apologize for even thinking about the possibility that something could be wrong and might require a fix.
>
> Have a good time!

A "discussion" 3 hours long, with 62.5% of posts in it being your own. One can understand how you'd give up after such a challenge.
You do realize that now it looks more like "implement it immediately or I ragequit!" kind of thing?