Idea #1 on integrating RC with GC

[Michel Fortin]

On 2014-02-04 23:51:35 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> 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.

I don't think it makes much sense. ARC when used for D constructs 
should be treated an alternate GC algorithm, not a different kind of 
pointer.

There's another possible use for ARC which is to manage 
reference-counted external objects not allocated by the D GC that are 
using reference counting (such as COM objects, or Objective-C objects). 
This could justify a different kind of pointer. But that's a separate 
issue from the GC algorithm used for D constructs.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca