On 2014-02-04 23:51:35 +0000, Andrei Alexandrescu
<[email protected]> 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
[email protected]
http://michelf.ca
