On Monday, 13 July 2015 at 06:49:10 UTC, Yuxuan Shui wrote:
The main reason here is to use '==' in @safe code:
class A {
override @safe bool opEquals(Object o) {
return cast(A)o !is null;
}
}
@safe void main() {
A a = new A;
A b = new A;
a == b;
}
This doesn't compile in current D, because objects.opEquals
takes two Object, and Object.opEquals is not @safe.
Why can't we have a template objects.opEquals?
auto opEquals(T, S)(T a, S b) { ... }
https://issues.dlang.org/show_bug.cgi?id=9769
In theory, the plan is to remove opEquals, opCmp, toString, and
toHash from Object so that they no longer force a particular set
of attributes on everyone. The free function, opEquals would be
templated as part of that (though the opEquals on a class could
not be templated and be a virtual function). Then folks would
define those functions on their derived classes without whatever
attributes they wanted.
Unfortunately, not a lot of work has been done towards removing
them from Object. I worked on templatizing the free function,
opEquals, previously, but compiler bugs prevented those changes
from being merged in. I need to try it again and see if it can be
made to work now. The AAs need to be redesigned for this to work
as well, and Martin Nowak has been doing work for that, but
that's not done yet AFAIK, and none of the other work which would
be required to remove those functions from Object has been done
(and compiler changes would likely be required in order to do it
in a way that didn't immediately break code).
So, ultimately, the free function, opEquals should end up being a
template function, and Object itself will no longer support
opEquals, but it's unlikely that opEquals on classes will end up
being templates, because then they wouldn't be virtual. But then,
they'd have whatever attributes a programmer but on their base
class rather than forcing a particular set of them like we do now.
- Jonathan M Davis
