Should opEquals be removed from object? (Was: Re: How to check

[Sean Kelly]

Robert Fraser wrote:
> Nathan Reed Wrote:
> 
>> Robert Fraser wrote:
>>> This one seems to trip up a lot of new users. Is there some way (short of making it huge, red, and flashing) to make this somehow more obvious o the D webpage. I'm sure it trips up quite a few people who already know the rule, too (I don't do too much D work, and I've already been bitten once or twice).
>>>
>>> I think the best way might be to issue a compiler error if an object doesn't have an opEquals() overload instead of providing a default implementation in object (like for all the other operator overloads). That would break a lot of existing code, though, but the compiler would help fix it rather than having it break silently.
>>>
>> How about just issuing a warning if 'null' is on either side of an == sign?
>>
>> Thanks,
>> Nathan Reed
> 
> I guess my problem is this (taken from object.d):
> 
> int opEquals(Object o)
> {
>     return cast(int)(this is o);
> }
> 
> All object.opEquals() is doing is invoking "is", so it's kind of tricking people who don't know/remember that == doesn't test for identity and theoretically (it'd probably be inlined, but still) slowing down code. What's the point? Seems like it'd be better all around to get rid of it entirely.

opEquals needs to be in Object because it is used by the AA code. 
However, it could be changed to simply throw an exception, thus 
requiring users to override it.


Sean