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