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.
