Idea #1 on integrating RC with GC

[woh]

He said *new* library type, so obviously it would not break 
existing code since nothing uses it.

  Wednesday, 5 February 2014 at 00:07:30 UTC, Adam Wilson wrote:
> On Tue, 04 Feb 2014 15:51:35 -0800, 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.
>>
>> Andrei
>
> I am assuming that you ignoring cyclic-refs for now. And 
> dealing with them would mean that you would need something like:
>
> auto @weak x = fun();
>
> Since the compiler cannot figure out that this is supposed to 
> be weak or not it would assume strong as that is the majority.
>
> Second thought. Why is their an extra step for those of us who 
> don't want the GC. I know there has to be an extra step for 
> some people, but I feel that we should make the simplest option 
> the default and then open up avenues for more advanced control 
> for people who want it. ARC is not as simple to understand as a 
> GC for newbies, and ARC requires more careful control, so why 
> not make getting into ARC a little harder, that way we prevent 
> heartache for new people. So something more like:
>
> auto x = fun().toARC();
>
> I can't imagine any situation where you could go from ARC to GC 
> that could not also go from GC to ARC, they have to be 
> equivalent operations to do that anyways.
>
> In the design world you make the simple option easy and more 
> the more advanced options harder to get at to reduce the chance 
> that the user accidentally shoot themselves in the foot. And 
> the guys who want to the advanced options are power users 
> anyways, they expect to have to work at it a little more.
>
> Related third thought. This goes against the current paradigm 
> and will subtly break existing D code that has cyclic-refs in 
> it.