Idea #1 on integrating RC with GC

[Andrei Alexandrescu]

On 2/5/14, 12:03 AM, Nick Sabalausky wrote:
> 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.

Yah. We'd then need to do something similar on the parameter side, e.g. 
extend isSomeString to comprehend the RC variety as well.

> 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;
>      }
> }

Nice. Though I'd say just return RC strings and let the client call 
toGC. They'd need to specify WantArc.No anyway so one way or another the 
user has to do something.


Andrei