On 25/07/14 06:50, Walter Bright wrote:
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).
The code [1] from the original issue, 13179, does have an opCmp which
handles equivalent.
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 still don't see the problem:
1. If neither opCmp or opEquals are defined, the compiler will
automatically generate these and will be used for comparison and equivalent
2. If opEquals is defined, lhs == rhs will be lowered to lhs.opEquals(rhs)
3. If opCmp is defined but no opEquals, lhs == rhs will be lowered to
lhs.opCmp(rhs) == 0
4. If opCmp and opEquals is defined, lhs == rhs will be lowered to
lhs.opEquals(rhs)
The only case this will break code is when opCmp was defined and
opEquals was not defined where lhs.opCmp(rhs) == 0 and lhs == rhs gave
different results. Many here think this is a bug in the first place. If
anything, this change would fix broken code.
[1]
https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/text/Regex.d#L2345
--
/Jacob Carlborg
