Am Wed, 05 Feb 2014 19:44:50 +0000 schrieb "Jameson Ernst" <[email protected]>:
> 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
