On Sunday, 11 October 2015 at 14:27:36 UTC, Freddy wrote:
On Sunday, 11 October 2015 at 06:10:32 UTC, Jonathan M Davis
wrote:
alias is problematic, because it allows the class reference to
escape. opDispatch doesn't have that problem, though there may
be other complications that it introduces (I don't know). It
does get kind of complicated though when you consider member
functions which return the a reference to the object and
things like that. So, while it's generally feasible, it's not
that hard for it to become unsafe. How much that matters is
debatable, but it could make it so that reference counting
classes is infeasible in @safe code.
- Jonathan M Davis
Can't we make opAssign and this(this) work with classes add
@disable to them? Also rec counted classes shouldn't have
members of that have their type, they should have to have
members of the aliased struct containing their type.
I don't know if opAssign can be overloaded for a class or not.
That gets a bit wonky IMHO given that you never assign classes -
only references to them. Similarly, class objects never get
postblitted. And something as simple as a parent-child
relationship tends to cause serious problems restricting
references to smart pointers. e.g. take this C++ code
class Parent
{
friend class Child;
public
Parent() _child(make_shared<Child>(this)) {}
private:
shared_ptr<Child> _child;
}
class Child
{
public:
Child(Parent* parent) : _parent(parent) {}
private:
Parent* _parent;
}
auto parent = make_shared<Parent>();
In this case in C++, because the ref-counting is not built-in to
the type, there is no way for the Child to have access to its
parent via a shared_ptr. It has to be done via a normal pointer.
D has exactly this same problem. If the ref-counting isn't
built-in, then there are cases where you have to let a
non-ref-counted reference escape.
The problem can be reduced by making it so that RefCounted (or
whatever the wrapper struct is) doesn't allow accidental, direct
access to the wrapped class object. But some stuff will simply be
impossible without providing direct access.
By having the class reference contain the reference count, the
problem can significantly reduced, because then it's possible to
create a shared pointer from the class object without ending up
with a separate reference count. But you still have the problem
of that class object being passed around and not necessarily
always being put in a wrapper object like it's supposed to be.
So, you still have a safety issue.
The only way for this to be completely safe is for the
ref-counting to be built into the language such that there is no
way to have a reference being passed around which isn't
ref-counted. Now, we can certainly take the approach of saying
that we don't care about that being completely safe (in which
case, ref-counting classes will be limited if not outright banned
in @safe code), but if we want @safe ref-counting, we have no
choice.
- Jonathan M Davis
