WAT: opCmp and opEquals woes

[Walter Bright via Digitalmars-d]

On 7/25/2014 7:08 AM, H. S. Teoh via Digitalmars-d wrote:
> You're missing the fact that:
>
> 1) Before we fixed the use of typeinfo.compare in aaA.d, users were
> *required* to define opCmp in order for their types to be usable as AA
> keys -- because that's what aaA.d used to compare keys. This applies
> even if the user type has no meaningful partial ordering -- you still
> had to define opCmp because otherwise it just plain won't work properly.

I'm not missing that at all. I wrote that requirement.


> 2) Because of (1), there's now code out there that defines opCmp for
> user types just so that they can be used as AA keys. But we're now
> breaking that by saying "nyah nyah we're now using opEquals for AA keys,
> so your opCmp don't work no more, sux to be you!".

No, we're not breaking code, unless the user wrote an opCmp that doesn't produce 
the same result as ==. This kind of struct would not make sense to use in an AA, 
and that code is most likely very rare and quite broken.


> From the perspective of the user, this can be extremely frustrating:
> prior to 2.066, they were told "you must define opCmp otherwise your AA
> keys won't work properly". So like obedient little lambs they went ahead
> and did that. And now in 2.066 we're saying "you must define opEquals
> otherwise your AA keys won't work properly

Nope. If the user doesn't write opEquals, the compiler will generate one for 
him, using the same method as it did for ==.


> The whole reason the opCmp()==0 thing was brought up, was to eliminate
> this frustration -- give users a nice way to transition into the correct
> AA design of using opEquals for their keys, instead of just outright
> breaking past recommendations in their face with no warning.

As I explained to Jacob, such a workaround will introduce subtle problems that 
are going to be hard to live with.