digitalmars.D - Make objects.opEquals a template?
- Yuxuan Shui (15/15) Jul 12 2015 The main reason here is to use '==' in @safe code:
- ketmar (7/26) Jul 13 2015 'case templates can't be virtual functions, so the following will not=20
- Yuxuan Shui (3/28) Jul 13 2015 What do you mean by virtual function? objects.opEquals is not a
- Jonathan M Davis (15/48) Jul 13 2015 Currently, Object has a function named opEquals which _is_ a
- Jonathan M Davis (26/41) Jul 13 2015 https://issues.dlang.org/show_bug.cgi?id=9769
- Yuxuan Shui (3/14) Jul 13 2015 No. I'm not trying to templatizing member function opEquals.
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) { ... }
Jul 12 2015
On Mon, 13 Jul 2015 06:49:09 +0000, Yuxuan Shui wrote:
The main reason here is to use '=3D=3D' in safe code:
=20
class A {
override safe bool opEquals(Object o) {
return cast(A)o !is null;
}
}
safe void main() {
A a =3D new A;
A b =3D new A;
a =3D=3D b;
}
=20
This doesn't compile in current D, because objects.opEquals takes two
Object, and Object.opEquals is not safe.
=20
Why can't we have a template objects.opEquals?
=20
auto opEquals(T, S)(T a, S b) { ... }
'case templates can't be virtual functions, so the following will not=20
work:
bool cmp (Object a, Object b) { return a.opQeuals(b); }
MyObj a, b;
cmp(a, b);
=
Jul 13 2015
On Monday, 13 July 2015 at 09:10:41 UTC, ketmar wrote:On Mon, 13 Jul 2015 06:49:09 +0000, Yuxuan Shui wrote:What do you mean by virtual function? objects.opEquals is not a member function.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) { ... }'case templates can't be virtual functions, so the following will not work: bool cmp (Object a, Object b) { return a.opQeuals(b); } MyObj a, b; cmp(a, b);
Jul 13 2015
"Jonathan M Davis" <jmdavisProg gmx.com> On Monday, 13 July 2015 at 09:13:06 UTC, Yuxuan Shui wrote:On Monday, 13 July 2015 at 09:10:41 UTC, ketmar wrote:Currently, Object has a function named opEquals which _is_ a member function, and it is largely the reason, why opEquals on classes cannot be safe - or pure, or nothrow - or even technically, const (though there's a hack in the free function, opEquals which casts away const to make const Objects comparable, which is a pretty dangerous thing to do in reality). Now, there is a free function called opEquals that calls the opEquals on a class object, and as I described in another post in this thread, it's supposed to be templatized at some point, but templatizing wouldn't allow you to have == be safe, pure, or nothrow. For that to work, opEquals on the class itself must have those attributes, and to do that, opEquals needs to be removed from Object (as I described in that other post). - Jonathan M DavisOn Mon, 13 Jul 2015 06:49:09 +0000, Yuxuan Shui wrote:What do you mean by virtual function? objects.opEquals is not a member function.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) { ... }'case templates can't be virtual functions, so the following will not work: bool cmp (Object a, Object b) { return a.opQeuals(b); } MyObj a, b; cmp(a, b);
Jul 13 2015
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
Jul 13 2015
On Monday, 13 July 2015 at 09:23:36 UTC, Jonathan M Davis wrote:On Monday, 13 July 2015 at 06:49:10 UTC, Yuxuan Shui wrote:No. I'm not trying to templatizing member function opEquals. Your post answered my question, thanks. Hope this gets done soon.[...]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. [...]
Jul 13 2015