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.
