On 7/25/14, 3:31 AM, Jonathan M Davis wrote:
On Friday, 25 July 2014 at 04:50:38 UTC, Walter Bright 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).
Exactly. The only reason that switching from using lhs.opCmp(rhs) == 0
to opEquals would break code is if a type does not define them such that
they're equivalent, which would mean that opEquals and/or opCmp was
defined in a buggy manner. So, the only way that the change would break
code is if it was broken in the first place. All it risks is making it
so that the bug exhibits itself in an additional case.
Not at all.
If you have a type that has partial ordering (only cares about opCmp,
not about opEquals), but still keeps the default opEquals, then this
would silently break someone's code by changing their opEquals semantic.
THIS is the breaking change.
