Should opEquals be removed from object?

Nathan Reed nathaniel.reed at gmail.com
Mon Aug 27 22:53:53 PDT 2007


Robert Fraser wrote:
> 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.

It probably should be removed, or replaced by a throw, but this doesn't 
change the fact that if you use == to test for null references, you get 
a runtime error and there's no indication of the problem at compile 
time.  A warning would be helpful (or even an error, since AFAIK there's 
no situation where writing 'o == null' is the right thing to do).

(OT) by the way, is there a reason opEquals returns int?  I'm sure 
people have pointed this out before, but bool would seem to be more natural.

Thanks,
Nathan Reed



More information about the Digitalmars-d mailing list