On 25 July 2014 14:50, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> On 7/23/2014 9:45 AM, H. S. Teoh via Digitalmars-d wrote: > >> https://issues.dlang.org/show_bug.cgi?id=13179 >> > > Consider also: > > http://www.reddit.com/r/programming/comments/2bl51j/ > programming_in_d_a_great_online_book_for_learning/cj75gm9 > > The current scheme breaks existing code - code that was formerly correct > and working. > > AAs don't make sense if the notion of == on members is invalid. AAs > formerly required opCmp, and yes, opCmp could be constructed to give > different results for opCmp==0 than ==, but I would expect such an object > to not be used in an AA, again because it doesn't make sense. > > Using the default generated opEquals for AAs may break code, such as the > an AA of the structs in the parent post, but it seems unlikely that that > code was correct anyway in an AA (as it would give erratic results). > > Kenji's rebuttal https://issues.dlang.org/show_bug.cgi?id=13179#c2 is > probably the best counter-argument, and I'd go with it if it didn't result > in code breakage. > I don't really see how opCmp == 0 could be unreliable or unintended. It was deliberately written by the author, so definitely not unintended, and I can't imagine anybody would ever deliberately ignore the == 0 case when implementing an opCmp, or produce logic that works for less or greater, but fails for equal. <= and >= are expressed by opCmp, which imply that testing for equality definitely works as the user intended. In lieu of an opEquals, how can a deliberately implemented opCmp, which we know works in the == case (otherwise <= or >= wouldn't work either) ever be a worse choice than an implicitly generated opEquals? Personally, just skimming through this thread, I find it baffling that this is controversial.
