DIP74: Reference Counted Class Objects

[Andrei Alexandrescu via Digitalmars-d]

On 2/26/15 5:43 PM, Andrei Alexandrescu wrote:
> The compiler will issue errors if returning ref to direct members. There
> won't be errors with returning ref to owned indirect members that the
> class deallocates manually. -- Andrei

To clarify this point, which I think is important, consider:

class Widget {
     private int x;
     private int[] a;
     ...
     ref int getX() { return x; }
     int[] getA() { return a; }
}

This is all fine and dandy - people can take and keep a reference to x 
in a GC object, and of course can get keep the array (or a portion of 
it) etc.

Now say we port Widget to an RC system:

class Widget {
     private int x;
     private int[] a;
     ...
     ref int getX() { return x; }
     int[] getA() { return a; }
     void opAddRef();
     void opRelease();
}

Not getX() does NOT compile anymore, whereas getA() CONTINUES to 
compile. To make getX() compile, the user must change code to:

     ref int getX() return { return x; }

That makes the compiler go, "oh ok I'll make sure the reference doesn't 
outlive the current object". And all is again fine and dandy.

Now if the person defining Widget wants to own (and release 
deterministically) the array, they must make sure their use of memory is 
scoped appropriately, e.g. by using RCSlice.


Andrei