Philosophy of how OS API imports are laid out in druntime

[Vladimir Panteleev]

On Thursday, 6 March 2014 at 21:35:34 UTC, Walter Bright wrote:
>> To clarify some points..
>>
>> @Walter are you asking for ALL includes even #include 
>> <windows.h> to map?
>
> Yes. Of course, if you're on linux and attempt to import 
> core.windows, you should expect a compilation failure, just as 
> you would in C with:
>
>     #include <windows.h>

I'm not sure about this.

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.

Consider, for example, the D module "core.time". POSIX has the 
header <time.h>. You have a collision right there.

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.