[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