Philosophy of how OS API imports are laid out in druntime

[Walter Bright]

On 3/6/2014 2:32 PM, Vladimir Panteleev wrote:
> First of all, even considering the idea of putting everything in one package, it
> should not be "core". There are many D-specific things in "core" right now. It's
> probably best to keep OS includes and D stuff differently.

Sure. The package name isn't important, it's what follows that is.


> Second, I think that the different ways with how C and D approach headers (list
> of include paths vs. module system and package hierarchy) warrants considering
> another solution. For example, at least on Windows, the compiler consults at
> least two include directories: the C runtime includes (for declarations that are
> part of C and whatever part of POSIX emulation is included), and the Windows
> SDK. Sometimes, components migrate from one project to another (e.g. DirectShow
> was moved out of the DirectX SDK and into the Windows Platform SDK). Thus I
> think it would be preferable to keep things organized in packages rather than
> flattening everything together.

What I want to see is a strong correspondence between what a C coder would write 
when #including system files, and the corresponding D import. What I object to are:

1. Trying to reinvent, improve, refactor, fix, clean up, etc., the OS api. This 
is not in D's charter. We have no resources to do it properly anyway.

2. Trying to split C's header files into separate posix / nonposix modules. As 
in (1), this is beyond the scope of what D is trying to do.

3. Pushing versioning into user code, as in:

     version (linux) import os.linux.whatever;
     else version (FreeBSD) import os.freebsd.whatever;
     ...
     else static assert(0);

as opposed to:

     import os.whatever;

I understand the sentiment that this will signal to the user that he's using 
non-portable imports, but I don't think it's worth it. Portability is what 
Phobos is for, not OS api interfaces.

4. Attempts to eliminate code duplication in OS api interface modules. A desire 
to do this comes up repeatedly. I can expand on this if anyone remains 
unconvinced :-)