WAT: opCmp and opEquals woes

[H. S. Teoh via Digitalmars-d]

On Fri, Jul 25, 2014 at 06:56:40PM +0000, Jonathan M Davis via Digitalmars-d wrote:
[...]
> So, if we remove the new check for a user-defined opEquals when opCmp
> is defined, then you don't have to define opEquals.

This is even worse, since it may silently introduce runtime breakage.
The original type may have had opCmp defined just so it can be used with
AA's, and now after the upgrade to 2.066, suddenly the custom opCmp code
they wrote specifically to work with AA's doesn't get used anymore, yet
the compiler silently accepts the code, and the problem won't be found
until runtime.


> If we do what H.S. Teoh suggests, then you'll have to define it if you
> want to avoid the additional checks that opCmp would be doing that
> opEquals wouldn't do, but if you didn't care, then you wouldn't.

Which IMO fits the D motto of being correct first, and performant if you
ask for it.


> If we leave it as it is in git master, then you'd always have to
> define it if you defined opCmp and wanted to use it as an AA key, and
> since opCmp was used for AA keys before, that means that _every_ type
> which didn't define opEquals but was used as an AA key will suddenly
> have to define opEquals and toHash and will thus now be broken. So,
> the current situation in git master is the worst all around.
[...]

Yes, it's clear that *something* need to be done about the current
situation in git master. It's just a question of what.

Having said that, though, I do agree that the current situation in git
master is the most *pedantically* correct, in the sense that it now
properly enforces correct usage of opCmp/opEquals/toHash. If we were
starting from scratch, I would definitely vote for the current
behaviour. The problem, however, is that we have to deal with the
historical baggage of existing code that was written to conform to the
old buggy AA design, and we'd like to minimize gratuitous code breakage.
The current situation in git master is a very poor way of handling this.

If people are opposed to making the default opEquals to be opCmp()==0
(if the user defines opCmp), could it at least be used as a deprecation
path for phasing out the old usage of opCmp for AA keys and migrating to
opEquals? That is, we introduce opEquals = (opCmp()==0) for 2.066 in
order to minimize code breakage, but put a deprecation notice on it, and
then remove it in 2.067 (or whatever the release will be given the
current deprecation cycle).


T

-- 
MASM = Mana Ada Sistem, Man!