On Tue, 04 Feb 2014 18:51:35 -0500, Andrei Alexandrescu
<[email protected]> 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
