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.
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.
Yeah. It wouldn't be all that bad to do something similar to
C++11 and make it so that we explicitly indicate when we want to
use the default opEquals (or toHash), but doing so would break
code, and outright just making it so that opEquals must be
defined when AAs are used without allowing a way for the
compiler-generated opEquals or toHash to be used seems very
broken to me. With such a change, _no_ existing user-defined type
would be able to use the built-in opEquals or toHash functions if
they're used with AAs, which is particularly bad in the case of
toHash, since that's much harder to get right.
- Jonathan M Davis
