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