[Issue 13179] AA key type TagIndex now requires equality rather than comparison

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13179

--- Comment #20 from Jacob Carlborg <doob at me.com> ---
(In reply to Jonathan M Davis from comment #19)
> Okay. Clearly, I was not paying enough attention to what was going on here.
> It always has been the case that opEquals is generated for for structs, if
> you don't define it. That hasn't changed for 2.066. Rather, in the case
> where you try and use it as an AA key, it now screams at you for not having
> defined opEquals, even though the default opEquals was almost certainly
> fine, because that's what was being used.
> 
> It's a major bug IMHO if lhs.opCmp(rhs) == 0 is not equivalent to lhs ==
> rhs, so if we change the AAs to use opEquals but do not give the error that
> we're currently giving, then all we'd be doing is exposing an existing bug
> in someone's code, and that bug probably exists elsewhere in their code,
> since they probably use opEquals with their keys _somewhere_.
> 
> And it seems kind of messed up to me to require that opEquals be defined
> just because you're using an AA when the default opEquals already does the
> right thing.
> 
> IMHO, we should either require that opEquals be defined in general if opCmp
> is defined (which I think is a bad idea), or we should just use the default
> opEquals with AAs without complaining about it (much better idea IMHO). The
> only code that would be negatively affected is already broken anyway. But
> requiring folks to define opEquals instead of using the perfectly good
> default just because they're using an AA seems very wrong to me.

If you define opCmp it means that the default generated isn't correct for you.
If the default opCmp isn't correct, how often will the default opEquals be
correct then. I mean, will there be uses where the default opEquals is correct
but not the default opCmp.

Generating opEquals to call opCmp == 0 if opCmp is defined will be a breaking
change but it will only change the behavior if previously lhs.opCmp(rhs) == 0
was _not_ the same as lhs == rhs, which you defined as a bug. So to me this
looks like it will fix bugs.

--