Idea #1 on integrating RC with GC

[Marco Leise]

Am Wed, 05 Feb 2014 19:44:50 +0000
schrieb "Jameson Ernst" <jameson at example.com>:

> I'm just a casual end-user of D, but have been following this and 
> related discussions with great interest. Just yesterday I was 
> trying to "sell" D to a friend, and he basically told me that 
> he'd be interested once the memory management situation gets 
> resolved. I've been thinking about this a lot lately, even though 
> I'm probably way out of my depth given the experts that frequent 
> this forum. Still, I had an idea about this and thought I'd throw 
> it out there.
> 
> On Wednesday, 5 February 2014 at 04:18:49 UTC, Andrei 
> Alexandrescu wrote:
> > On 2/4/14, 5:12 PM, deadalnix wrote:
> >> That being understood, I'd rather connect things the other way 
> >> around.
> >>
> >> auto x = foo();
> >> auto x = foo().toRC();
> >
> > I don't know how to implement that.
> >
> >
> > Andrei
> 
>  From the discussion currently going on about postblits, it seems 
> like there's a new emerging concept of a "unique expression," the 
> value of which is guaranteed not to be referenced elsewhere. 
> Could this concept perhaps be leveraged to go backwards from GC 
> to RC? If you perform a GC allocation in the context of a unique 
> expression, would it then be safe to force it back into an RC 
> context, knowing that there are no outstanding references to it? 
> What's more, it would allow library writes to mostly perform 
> allocations a single way, giving the choice to the caller how 
> they'd like to manage the lifetime of the newly returned unique 
> object.
> 
> I could be completely misunderstanding the unique-expression 
> concept though.

The intent is to make it possible to avoid the GC, but if I
understand you correctly you talk about always allocating
through the GC first.

-- 
Marco