WAT: opCmp and opEquals woes

[Jonathan M Davis via Digitalmars-d]

On Friday, 25 July 2014 at 19:03:16 UTC, Marc Schütz wrote:
> On Friday, 25 July 2014 at 18:45:30 UTC, Jonathan M Davis wrote:
>> And remember that a lot of types have opCmp just to work with 
>> AAs, so all of a sudden, _every_ user-defined type which is 
>> used as an AA key will have to define toHash.
>
> No, if a type had only defined opCmp because of the previous AA 
> (mis)implementation, it needs to be changed with any of the 
> suggested solutions: If opEquals is not going to be 
> auto-generated, the user needs to add it, if it is, the user 
> has the choice between adding toHash, or (more likely, as opCmp 
> usually isn't necessary) changing opCmp into opEquals.

No, if the opCmp is consistent with the default-generated 
opEquals, then there's no need to define either opEquals or 
opCmp. And if opCmp was inconsistent with the default opEquals, 
then toHash would have already had to have been defined to be 
consistent with opCmp, or the AA wouldn't have worked properly 
regardless.

So, if we let opEquals and toHash continue to be generated by the 
compiler when opCmp is defined, the only folks who would now have 
to define opEquals or toHash who didn't before would be the folks 
who should have been defining them previously to be consistent 
with opCmp but didn't. Whereas with the current git master, 
they'd all have to define opEquals and toHash. With H.S. Teoh's 
suggestion, opEquals wouldn't have to be defined but toHash would 
(since the compiler has no way of knowing that lhs.opCmp(rhs) == 
0 is equivalent to the default opEquals that the default toHash 
is consistent with).

The current option breaks all AA-related code that didn't define 
opEquals and toHash already (which a lot of code didn't have to 
do), and H.S. Teoh's option breaks all AA-related code that 
didn't define toHash already. So, the option that causes the 
least code breakage is to let the compiler continue to define 
opEquals and toHash as it has, even if opCmp has been defined. 
The only risk is if opCmp wasn't consistent with the default 
opEquals, but if that's the case, the code was already broken 
anyway.

- Jonathan M Davis