Idea #1 on integrating RC with GC

[Andrei Alexandrescu]

On 2/5/14, 4:39 AM, Manu wrote:
> On 5 February 2014 09:51, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org <mailto: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.

How do you mean that?

> What about closures?

This is "#1" and it only addresses slices.

> What about allocations from phobos?

Phobos would get added support for RC slices.

> What
> about allocations from 3rd party libs that I have no control over?

Outside the charter of this discussion.

> I don't like that it requires additional specification, and special
> treatment to have it detach to the GC.

But you didn't like that GC is implicit. Which way do you want it?

> There's nothing transparent about that.

I don't think we can attain 100% transparency.

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

This is technically possible today.


Andrei