Philosophy of how OS API imports are laid out in druntime

[Iain Buclaw]

On 6 March 2014 22:53, Walter Bright <newshound2 at digitalmars.com> wrote:
> 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.
>

I don't think that is what druntime does in terms of it's C
interfacing modules.  What it does do is make it more logical for
people to find what they are looking for, or if they want to make
changes, which areas to look at.


> 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.
>

I think the word posix seems to be the cesspool that's repeatedly
brought up here to fan the flames here.   What about the
linux/freebsd/osx/windows packages?


> 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.
>

This is something that needs to be worked on, but I'm not convinced a
flat hierachy will solve anything.

Regards
Iain