WAT: opCmp and opEquals woes

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 24 23:31:39 PDT 2014


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


More information about the Digitalmars-d mailing list