Idea #1 on integrating RC with GC

[Steven Schveighoffer]

On Tue, 04 Feb 2014 18:51:35 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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.

Doesn't that mean it lives in the GC heap and is scanned along with all  
the other data in the GC heap (and triggers GC cycles)? What is the  
benefit?

> 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();

Shouldn't the default be what is expected now? That is, I don't want to  
have to change all my code to return RCSlice!T instead of T[]. I admit, I  
don't know how that would work...

-Steve