Idea #1 on integrating RC with GC

[Andrei Alexandrescu]

On 2/6/14, 12:28 AM, luka8088 wrote:
> On 5.2.2014. 0:51, Andrei Alexandrescu wrote:
>> Consider we add a library slice type called RCSlice!T. It would have the
>> same primitives as T[] but would use reference counting through and
>> through. When the last reference count is gone, the buffer underlying
>> the slice is freed. The underlying allocator will be the GC allocator.
>>
>> Now, what if someone doesn't care about the whole RC thing and aims at
>> convenience? There would be a method .toGC that just detaches the slice
>> and disables the reference counter (e.g. by setting it to uint.max/2 or
>> whatever).
>>
>> Then people who want reference counting say
>>
>> auto x = fun();
>>
>> and those who don't care say:
>>
>> auto x = fun().toGC();
>>
>>
>> Destroy.
>>
>> Andrei
>
> Here is a thought:
>
> Let's say we have class A and class B, and class A accepts references to
> B as children:
>
> class A {
>    B child1;
>    B child2;
>    B child3;
> }
>
> I think that the ultimate goal is to allow the user to choose between
> kinds of memory management, especially between automatic and manual. The
> problem here is that class A needs to be aware whether memory management
> is manual or automatic. And it seems to me that a new type qualifier is
> a way to go:
>
> class A {
>    garbageCollected(B) child1;
>    referenceCounted(B) child2;
>    manualMemory(B) child3;
> }

There common theme here is that the original post introduces two 
distinct types of slices, depending on how they are to be freed (by 
refcounting or tracing).

Andrei