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

[Robert Fraser]

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.