Should opEquals be removed from object?

Bill Baxter dnewsgroup at billbaxter.com
Mon Aug 27 23:19:54 PDT 2007


Nathan Reed wrote:
> 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.
> 

About the opEquals return value:
http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/OperatorOverloading

--bb



More information about the Digitalmars-d mailing list