DIP74 - where is at?

[Jonathan M Davis via Digitalmars-d]

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