DIP74: Reference Counted Class Objects

[deadalnix via Digitalmars-d]

On Friday, 27 February 2015 at 02:05:33 UTC, Andrei Alexandrescu 
wrote:
> 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

It is the same with a pointer to a struct.