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