Idea #1 on integrating RC with GC

[Nick Sabalausky]

On 2/5/2014 2:21 AM, Andrei Alexandrescu wrote:
> On 2/4/14, 11:20 PM, Jesse Phillips wrote:
>> On Tuesday, 4 February 2014 at 23:51:35 UTC, Andrei Alexandrescu wrote:
>>> and those who don't care say:
>>>
>>> auto x = fun().toGC();
>>
>> If I don't care, why would I place .toGC() at the end of my calls?
>
> This is the way it all works: RC+GC is more structure than GC, so you
> start with more structure and then optionally "forget" it.
>
>> What
>> reason do I have to go out of my way to request this?
>
> You use an API that uses e.g. string, not RCString.
>

IIUC, it sounds like it'd work like this:

// Library author provides either one or both of these:
T[] getFooGC() {...}
RCSlice!T getFooARC() {...}

And then if, for whatever reason, you have a RCSlice!T and need to pass 
it to something that expects a T[], then you can cancel the RC-ing via toGC.

If that's so, then I'd think lib authors could easily provide APIs that 
offer GC by default and ARC as an opt-in choice with templating:

enum WantARC { Yes, No }
auto getFoo(WantARC arc = WantARC.No)() {
     static if(arc == WantARC.No)
         return getFoo().toGC();
     else {
	RCSlice!T x = ...;
         return x;
     }
}
T[] fooGC = getFoo();
RCSlice!T = getFoo!(WantARC.Yes)();

And I imagine that boilerplate could be encapsulated in a utility template:

private RCSlice!T getFooARC() {
     RCSlice!T x = ...;
     return x;
}
template makeGCDefault(...){...magic happens here...}
alias getFoo = makeGCDefault!getFooARC;