@nogc and NSAutoReleasePool-style regions.

[via Digitalmars-d]

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?

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