Behavior of opEquals

[Jonathan M Davis via Digitalmars-d]

On Saturday, 5 September 2015 at 09:45:36 UTC, Jacob Carlborg 
wrote:
> On 2015-09-05 08:26, Jonathan M Davis wrote:
>
>> Clearly, you haven't read TDPL recently enough. ;)
>>
>> There is a free function, opEquals, in object.d which gets 
>> called for
>> classes, and _it_ is what == gets translated to for classes, 
>> and it
>> calls the member function version of opEquals on classes:
>>
>> https://github.com/D-Programming-Language/druntime/blob/master/src/object.d#L143
>>
>>
>> This allows us to avoid a number of fun bugs with opEquals 
>> that you get
>> in languages like Java and makes it completely unnecessary to 
>> do stuff
>> like check whether the argument to opEquals is null. Timon 
>> gave the link
>> to the explanation in the spec:
>
> Bu you don't see my example as a problem?

Well, it might be a bit annoying, but it's simply a matter of 
adjusting your code to call opEquals explicitly when trying to 
call the base version, whereas without the free function 
opEquals, you have subtle correctness problems. For instance, if 
you have base == derived and derived == base, you'll get the same 
result for both for D, whereas the equivalent Java or C# could 
would likely not, because the free function opEquals checks both 
lhs.opEquals(rhs) and rhs.OpEquals(lhs) whether you did base == 
derived or derived == base.

So, while what we have is by no means perfect, I think that it is 
an improvement over what Java and C# did.

- Jonathan M Davis