Re: Philosophy of how OS API imports are laid out in druntime

[Walter Bright]

On 3/6/2014 3:51 PM, Iain Buclaw wrote:
On 6 March 2014 22:53, Walter Bright <newshou...@digitalmars.com> wrote:
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.

Usually not. But proposals to do such come up now and then - I just want to head 
these off before anyone invests effort in it.


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.

Eh, "more logical" is a trap. I'd prefer a simple 1:1 correspondence between C 
and D for OS api's. Then there's nothing clever about it, no decisions to make, 
and the user familiar with C will know where it is.


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?

Eliminate the linux/freebsd/osx/windows package inventions. I don't see in C 
code:

    #include <sys/linux/sys/foo.h>

so why should we do that? Again, what I propose is really simple from a user 
point of view - a 1:1 mapping between what he'd type in for C vs what he'd type 
in for D.


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.

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);