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
