[Dlang-study] [lifetime] Few root decisions to take on RC classes

[Andrei Alexandrescu]

On 11/02/2015 06:28 PM, Martin Nowak wrote:
> What if I want to use an existing (GC) class as ref counted, something
> like core.thread.Thread?

I suspect converting a GC class to an @rc class would require at least 
changes wrt escaping addresses of members.

> Tacking @rc on it would break some existing
> code, but not doing it requires the GC.

Probably that's the general case. But if a class has no public data 
members and member functions that don't leak member addresses, it stands 
to reason conversion could break no code.

> Same goes for specifying an allocator to use with a ref counted class.

I don't understand this part, could you please detail.

> It seems like a much better idea to decide that when using the class as
> opposed to when implementing the class.

Such an approach would need to first define which subset of classes work 
with both GC and RC. Do we agree on that? For example, classes that 
escape addresses of data members work safely only with GC. Same goes 
about classes that escape "this".

For my money, I have long looked for a way to implement reference 
counting outside of the class definition. I had my mind modeled after 
the C++ approach, and it does seem like a very sensible idea. Lately, 
however, I got disabused about the notion because I figured the set of 
manipulations allowed to GC classes largely surpasses the set of 
manipulations allowed to RC classes.

I am curious how you think you can define these two subsets.


Andrei