Philosophy of how OS API imports are laid out in druntime

[Sean Kelly]

The conversation began with Iain talking about how to improve
things from a maintenance perspective and was kind of sidetracked
by my and Walter's discussion.  I agree that something should be
done to address Iain's issue and think his suggestions sound
pretty good.  But concerning the rest...

Druntime has always been intended to contain the runtime code,
public interfaces to that runtime, plus core functionality that
could be considered essential or intrinsic to the language, a bit
like java.lang.

Having C headers there at all has always been more a matter of
necessity than design, since Druntime needs them for its own use.
   To my knowledge, it's always been a goal to minimize or at least
gently discourage direct use of C routines.  So the declarations
are there when needed, but tucked away in identifiable packages
so their use in an application can be easily determined via grep.
   This also serves an an indicator of where D might be lacking
from a functional perspective, as I don't think we want to
provide a standard library where users feel the need to lean on
another language's standard library.  Thus using libc as a
resource for the implementation of Druntime is more an artifact
of the age of the language than by design, though I'll grant that
it's nearly impossible to get away from using at least kernel
calls in many cases (I think we could absolutely do away with all
use of standard C routines).

My primary concern with Walter's proposal is that it violates the
principal I outlined above by placing the C headers front and
center in core.  It would effectively turn Druntime into a C
interface library, which is vastly different than its original
design goals.  If this is the intent, I propose creating a new
project on github for this purpose.  Otherwise, perhaps some
location beneath the root core package could be chosen for these
to live?  Perhaps just publish everything to core.sys, since that
package already exists?  I admit to completely not understanding
the claim that declarations are hard to find.  But then I
designed the current layout so it clearly makes sense to me.

As far as maintenance is concerned, while I do appreciate that it
becomes untenable to hold the declarations for every platform in
a single module as we have now, say, in core.stdc, I question the
claim that direct conversion of a platform's header files is
somehow less work than cherry-picking declarations according to
some standard.  As I've said before, I believe that automatic
conversion of headers may be considered a copyright violation (by
my reading of the license discussion on the Boost website), and
so manual conversion is our only option.  Given this, and having
all of the work creating and maintaining core.stdc and
core.sys.posix until a few years ago, I would have lost my mind
if I'd had to convert entire headers as-is rather than
cherry-picking declarations.  These headers are so big and so
filled with preprocessor macros and such that replicating the
entirety of what they contained in D code would have been a
nightmare.  But perhaps someone has a good answer for this that I
missed.  I certainly have no desire to maintain these headers in
any manner.  The current approach was simply the one I found that
required the least work.  If there's a way to do it with even
less then I'm all for it.

So I apologize for my part in derailing Iain's discussion.  I
suspect that there's a straightforward solution that's simply
been overlooked from Walter and me talking at cross-purposes.