Idea #1 on integrating RC with GC

[Manu]

On 5 February 2014 09:51, 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.
>
> 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.


This doesn't excite me at all.
What about all other types of allocations? I don't want to mangle my types.
What about closures? What about allocations from phobos? What about
allocations from 3rd party libs that I have no control over?
I don't like that it requires additional specification, and special
treatment to have it detach to the GC.
There's nothing transparent about that. Another library solution like
RefCounted doesn't address the problem.

Counter question; why approach it this way?
Is there a reason that it needs to be of one kind or the other?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140205/544877f6/attachment.html>