@nogc and NSAutoReleasePool-style regions.

[via Digitalmars-d]

On Wednesday, 9 July 2014 at 12:01:12 UTC, Marc Schütz wrote:
>> Sounds a lot like "pure", but not quite matching up?
>
> Well, `scope` was supposed to be that, but it's unimplemented 
> and not completely thought through.

*nods*

> Thinking aloud: If we could distinguish GC pointers from non-GC 
> pointers, we could apply the ownership information to them 
> "after the fact". Any GC pointer that comes out from your 
> library functions inside an auto-release block can be confined 
> to inside that block, or to the lifetime of the allocator. 
> (That is, only _newly allocated_ GC pointers inside those 
> blocks...)

For the @nogc+region allocator GC pointers could be helpeful. And 
as I tried to point out in another thread on GC performance, it 
could also provide precise GC collection performance benefits if 
you also clustered the GC pointers in objects at a negative 
offset (thus getting them onto the same cachelines even though 
they originate in deep sub-classes as well as super.classes).

Another benefit with explicit GC pointers is that you could ban 
GC pointers to classes that provide destructors, sanitizing the 
constructor/destructor situation.