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
