WAT: opCmp and opEquals woes
Jonathan M Davis via Digitalmars-d
digitalmars-d at puremagic.com
Fri Jul 25 13:24:15 PDT 2014
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
More information about the Digitalmars-d
mailing list