@nogc and NSAutoReleasePool-style regions.

[via Digitalmars-d]

On Tuesday, 8 July 2014 at 21:17:50 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 8 July 2014 at 20:38:59 UTC, Marc Schütz wrote:
>> But as you already noted, there needs to be a mechanism to 
>> restrict escaping of pointers.
>
> Yes, there ought to be, at least for @safe code.
>
>> Do you have some concrete idea how that could be solved?
>
> For my use, yes. Since I am considering a D-version for game 
> server development that does whole program analysis and might 
> put additional restrictions on the language. I'd like to 
> restrict the language to the extent that I can generate C code 
> for portability (server/client code sharing)…
>
> However, it should be possible with more local annotations too, 
> but maybe the existing ones that D provides are too weak or too 
> strong?
>
> One needs to prevent escaping, that means:
>
> 1. prevent writing through global variables (but allow reading 
> values, but not reading references for writing?)
>
> 2. prevent establishing new global contexts (threads and fibers)
>
> 3. putting limitations on the in-parameters to functions called 
> within the region-allocator block so they don't allow writing 
> to global contexts
>
> 4. ???
>
> 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.

>
>> A more or less straight-forward way would be to encode the 
>> ownership/lifetime information somewhere in the types of the 
>> pointers (similar to how we use const and the like today). But 
>> this cannot be done, because it could not apply to external 
>> (non-template) functions.
>
> It would be nice if it could fit into the current 
> infrastructure… but all suggestions are interesting. I think it 
> could be a nice way to get "gc" level convinience during spin 
> up of a server when you have plenty of memory available (you 
> can afford to be wasteful before you load in the main data).

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...)