WAT: opCmp and opEquals woes

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 23 July 2014 at 18:53:57 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Wed, Jul 23, 2014 at 11:48:42AM -0700, Andrei Alexandrescu 
> via Digitalmars-d wrote:
>> On 7/23/14, 9:45 AM, H. S. Teoh via Digitalmars-d wrote:
>> >Why isn't "a==b" rewritten as "a.opCmp(b)==0"?? I'm pretty 
>> >sure TDPL
>> >says this is the case (unfortunately I'm at work so I can't 
>> >check my
>> >copy of TDPL).
>> >
>> >https://issues.dlang.org/show_bug.cgi?id=13179
>> >
>> >:-(
>> 
>> It's a good decision. There are types that are comparable for 
>> equality
>> but not compared for ordering. -- Andrei
>
> That's the wrong way round. I fully agree that we should not
> autogenerate opCmp if the user defines opEquals, since not all 
> types
> comparable with equality are orderable.  However, surely all 
> orderable
> types are equality-comparable! Therefore, if opCmp is defined 
> but
> opEquals isn't, then we should autogenerate opEquals to be the 
> same as
> a.opCmp(b)==0.

That would incur a silent performance hit. We should either force 
the programmer to define opEquals (even if they just make it 
return a.opCmp(b) == 0) or we should keep the normal, generated 
one.

The best option though would be to provide some way for the 
programmer to tell the compiler that they want to use the default 
one so that they still have to declare opEquals when they define 
opCmp (to make sure that the programmer didn't forget it), but 
they're still able to use the built-in one rather than writing it 
themselves. IIRC, C++11 has a way of doing that. Maybe we should 
add something similar.

- Jonathan M Davis