WAT: opCmp and opEquals woes

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Fri Jul 25 07:08:23 PDT 2014


On Fri, Jul 25, 2014 at 02:37:46AM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/25/2014 2:12 AM, Jacob Carlborg wrote:
> >On 25/07/14 10:48, Walter Bright wrote:
> >>Putting it simply,
> >>
> >>1. == uses opEquals. If you don't supply opEquals, the compiler will
> >>make one for you.
> >>
> >>2. AAs use ==. See rule 1.
> >>
> >>
> >>Easy to understand, easy to explain, easy to document.
> >
> >It's very hard to use D when it constantly changes and breaks code.
> >It's especially annoying reading your comments on reddit that we must
> >stop break code. Then a few days later go an break code. I really
> >hope no one gets false hopes from those comments.
> 
> We went through the likely code breakage from this in this thread, and
> it's hard to see any non-broken code breaking. It will also fix
> regression https://issues.dlang.org/show_bug.cgi?id=13179 and stop
> that breakage.

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.

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!".

>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 -- and all your opCmp's are
now useless 'cos that was wrong in the first place". From the
perspective of the user, this seems like unreasonable code breakage --
first they *already* expected in the past that their code should've
worked with opEquals, but they were told to use opCmp because AA's were
buggy. Yet now we're going back on our word and saying that opCmp was
wrong -- the very workaround we recommended in the past -- and that now
they need to define opEquals instead, which didn't work before.  This
gives users the perception that we're constantly going back on our word
and breaking prior code and annulling previously recommended workarounds
without any warning.

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.


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com


More information about the Digitalmars-d mailing list