WAT: opCmp and opEquals woes

[Jacob Carlborg via Digitalmars-d]

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