A small proposal to introduce such a facility into druntime.

See PR for preliminary API:
https://github.com/D-Programming-Language/druntime/pull/653

In focus is to provide a unified API that allows the most common scenarios to work efficiently:
 - allocating memory that has executable permissions
 - reserve and commit memory pages gradually
 - (un)locking of memory in physical RAM
 - getting the OS page size

And another one case I haven't yet found a way to implement/use portably:
 - guard pages

Platforms diverge significantly enough that there is not even a remote chance to have 100% efficient wrapper for all potential uses cases. But most of them should be possible with a bit of overhead.

Same reservations apply to any attempt to accommodate for each platform's special tricks (they are simply not portable).

-- 
Dmitry Olshansky

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.

On Thursday, 31 October 2013 at 18:40:16 UTC, Jakob Ovrum wrote:
> ...

Very true. I sincerely believe that at some point guideline "always use scope local imports when possible, with either short alias or explicit imported symbol list" will be in every single D cookbook. Most trouble with D module system come from habit of simply throwing in top-level imports like it was done with C/C++ includes.