Philosophy of how OS API imports are laid out in druntime

[Sean Kelly]

On Friday, 7 March 2014 at 00:53:18 UTC, Walter Bright wrote:
>
> What it will solve is when the user reads the OS api 
> documentation, and it says:
>
>     #include <sys/ioctl.h>
>
> then the user knows that in D he has to do:
>
>     import whatever.sys.ioctl;
>
> What the user should not have to do is:
>
>     version (linux) import whatever.linux.sys.ioctl;
>     else version (FreeBSD) import whatever.freebsd.sys.ioctl;
>     else version (OSX) import whatever.osx.sys.ioctl;
>     ...
>     else static assert(0);
>
> nor:
>
>     import whatever.posix.sys.ioctl;
>     version (linux) import whatever.linux.sys.ioctl;
>     else version (FreeBSD) import whatever.freebsd.sys.ioctl;
>     else version (OSX) import whatever.osx.sys.ioctl;
>     ...
>     else static assert(0);

Toe be fair, I expect the user would almost never be importing
platform-specific headers.  Importing the posix headers is all
that should be needed in the common case.  Or if you need
something platform-specific, then don't import the posix header
because doing so is redundant--the platform header publicly
imports it anyway.

However, as much as I like that having the Posix headers strongly
encourages the user to write portable code, I can see the idea
doesn't have a lot of traction around here.  I beleive Iain's
proposal is to phase them out and do exactly what you suggest,
only to make "whatever" "core.foo" rather than simply "core".
Which works for me as well.