Idea #1 on integrating RC with GC

[Adam Wilson]

On Tue, 04 Feb 2014 18:08:32 -0800, Sean Kelly <sean at invisibleduck.org>  
wrote:

> On Wednesday, 5 February 2014 at 01:52:48 UTC, Adam Wilson wrote:
>> On Tue, 04 Feb 2014 17:12:37 -0800, deadalnix <deadalnix at gmail.com>  
>> wrote:
>>
>>> On Tuesday, 4 February 2014 at 23:51:35 UTC, Andrei Alexandrescu 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.
>>>>
>>>> Andrei
>>>
>>> RC need GC to collect loops. So you want to have the GC at the lowest  
>>> level.
>>>
>>> That being understood, I'd rather connect things the other way around.
>>>
>>> auto x = foo();
>>> auto x = foo().toRC();
>>
>> The ARC crowd is going to hate this because it's still a GC allocation  
>> then you hook it to RC. So they can still have random GC pauses.
>
> GC.disable. Just saying.

Hmm, as long as it doesn't disable the allocation that might just work.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator