Portable virtual memory management

[Jakob Ovrum]

On Thursday, 31 October 2013 at 18:07:07 UTC, Dmitry Olshansky 
wrote:
> A small proposal to introduce such a facility into druntime.

I'll move the pseudo-namespace issue here:

Currently it uses a struct `VMM` where all members are static as 
a namespace, much like `core.memory.GC`. However, IIRC, this 
practice has since been discussed at length, and I think the 
consensus has consistently been that it is generally a bad idea, 
and that it should be avoided for new code.

The obvious argument for using a pseudo-namespace is that the 
symbols would be too prone to collision or ambiguity if they were 
module-level. Indeed the names at hand are arguably very generic, 
examples including "allocate", "free" and "reserve".

However, the problem statement assumes that the module is 
imported plainly as `import core.vmm;` at module-level scope. The 
issue can be resolved flexibly by using other import forms, such 
as renamed or selective imports, and/or by using scoped imports.

At module-level it could be `import vmm = core.vmm;`, and when 
scoped it could be just `import core.vmm;` or `import core.vmm : 
allocate, free;`, eliminating the ambiguity, both for the 
compiler and the programmer. Of course, selective imports can be 
renamed as well, so another solution could be `import vmm : 
vmmAlloc = allocate, vmmFree = free` even in a broader scope such 
as the module-level scope.

I think by using a pseudo-namespace or a fixed name prefix 
(essentially the same thing), the user is locked into one 
solution, but by simply placing them at module-level scope with 
their undecorated names, the client can solve the problem in ways 
that best fit the client code.

I think names such as `std.algorithm.copy/map` and 
`std.file.read/write` is good precedent that shows that D can 
handle these generic, module-level symbol names without creating 
unreadable code, and it should be clear to most of the community 
by now that we have the tools necessary to avoid name collision 
errors.

AFAIK, the `core.memory.GC` struct stems from the Tango tradition 
of using structs as pseudo-namespaces, which I think is a less 
relevant practice now that we have scoped imports and a 
(slightly) less buggy module system.