[Dlang-study] [lifetime] Initial thoughts on lifetime management

Timon Gehr timon.gehr at gmx.ch
Wed Oct 28 06:44:43 PDT 2015


On Wednesday, 28 October 2015 at 00:45:00 UTC, Andrei 
Alexandrescu wrote:
> ...
>
> We need for D a form of shared ownership that is not backed up 
> by a tracing garbage collector, and one obvious choice is 
> reference counting.
> ...
>

> Here there are two options we discussed - an @rc attribute, or 
> simple
> detection of a pair such as opInc/opDec. I've argued for the 
> latter but Walter made a good argument for @rc: it gives the 
> compiler complete
> control over "as-if" style optimizations.

opInc and opDec are still useful. E.g. one could @disable opInc 
to obtain unique class references. (opInc and opDec are basically 
just class reference based versions of this(this) and ~this().)

How does the compiler lose control with opInc/opDec? It could 
still fuse them.

> Such classes:
>
> * do not inherit Object. (Do we want a root of all @rc classes 
> called RCObject?)
> ...

If we want to be able to elide the vptr, I don't think a common 
root class can work.

> * cannot be converted to interfaces (we may later add @rc 
> interfaces)
>
> * embed an implementation-defined reference count as a hidden 
> member
> ...

I think this should be configurable.

> * have a vptr only if they define non-final methods (in 
> particular, I think we should disable "synchronized" for them - 
> it seems an unnecessary complication at least for v1)
>
> * should they have a hidden pointer to the parent scope if 
> nested?
> 

Probably not if the parent scope is @rc.

How to specify the allocator for a @rc class?




More information about the Dlang-study mailing list