DIP74: Reference Counted Class Objects

[Jacob Carlborg via Digitalmars-d]

On 2015-02-26 22:50, Andrei Alexandrescu wrote:
> http://wiki.dlang.org/DIP74 got to reviewable form. Please destroy and
> discuss.

* What will happen if these methods are defined on a class that is 
allocated on the GC? Is there any enforcement against this? Is there any 
way an unsafe operation can happen, i.e. the GC deleting a class that 
has already been destroyed by reference counting?

What about enforcing a third method, "allocate" or similar. This method 
will do the actually allocation of a class instance. "new Foo" could be 
lowered to a call to "allocate".

* I know this is bikeshedding but I think it's important. This is a 
breaking change, like it or not, and it's the worst kind. The kind that 
if a class exists with these methods it will continue to happily compile 
without errors or warnings but will have different semantic behavior. 
Therefore I recommend requiring a compiler recognized UDA, in one of the 
following ways:

A.

@arc class Foo
{
     T1 opAddRef();
     T2 opRelease();
}

If a class is marked with @arc the compiler will enforce that both 
"opAddRef" and "opRelease" are defined with the expected signatures.

B.

class Foo
{
     @arc T1 opAddRef();
     @arc T2 opRelease();
}

If either a method is called "opAddRef" or "opRelease" and it's marked 
with @arc, the compiler will enforce that the other method is defined 
and marked with @arc as well. The signatures of the methods are enforced 
as well.

C.

class Foo
{
     @arc("addRef") T1 foo();
     @arc("release") T2 bar();
}

Basically the same as B but the actual methods can be called anything.

Alternative A gives a clear documentation it's a reference counted class 
without having to scan the methods.

-- 
/Jacob Carlborg