WAT: opCmp and opEquals woes

[Jonathan M Davis via Digitalmars-d]

On Thursday, 24 July 2014 at 21:54:01 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> On Thu, Jul 24, 2014 at 08:36:02PM +0000, Jonathan M Davis via 
> Digitalmars-d wrote:
>> And IMHO, having the default opEquals continue to be generated 
>> when
>> opCmp is defined is a very workable solution, since no types 
>> should
>> have defined opCmp in
>> a way that was inconsistent with opEquals.
> [...]
>
> Keep in mind that the last sentence means that wrong code (i.e.
> inconsistent opCmp/opEquals) will silently compile and 
> misbehave at
> runtime.

Well, that's exactly the behavior in 2.065 from what I can tell. 
If you don't define opEquals, the compiler defines it for you 
even if you defined opCmp. And trying out git head, it does 
exactly the same thing. You only get a compilation error when 
using AAs, which is pretty weird IMHO, and it seems very wrong to 
suddenly require that opEquals be defined when the default is 
still being generated. The only way that anyone is going to have 
problems is if their opCmp is not consistent with opEquals, which 
is just plain a bug IMHO, so if switching the AAs to opEquals 
instead of opCmp causes bugs, you're just swapping one set of 
bugs for another, which seems fine to me. Certainly, I think that 
it's stupid to require that opEquals be defined just because 
you're using the type as an AA key when it's not required 
otherwise.

- Jonathan M Davis