On May 8, 2012, at 2:31 PM, Jonathan M Davis wrote: > > We've previously discussed having _all_ of the C system call functions from > the various OSes that we support being in druntime, and I very much think > that > that's the right way to go. Phobos and druntime then have whatever they need > as for as standard C and system call functions go, and anyone who needs any > which aren't wrapped by Phobos in some manner has them available to them. > Anyone that doesn't want to use any of those C function directly, doesn't > have > to, but I don't see any reason to hide them just because someone doesn't want > to use them in their code. > > If the problem is that certain C functions end up getting used a lot when > they > should have D wrappers of some kind which better encapsulate their > functionality, then maybe we add the appropriate wrappers to Phobos. But > that's a completely different issue. Hiding the C functions doesn't help us > any.
I personally use "import core.stdc" as an indicator that there may be some feature missing from Phobos. It's easily greppable, and easy to avoid using the routines. In fact, I think "import core" anything should be an exceptional case in a typical D application. Everything exposed in Druntime is for what I'd consider power users. Unsafe threads, runtime and GC hooks, platform API calls, etc. It's all there because the higher-level stuff needs it, but is really not intended for general use. > It makes sense to make truly internal stuff internal, but the standard C > function declarations and OS system functions are _not_ internal to druntime. > They're _very_ much external. druntime is just providing them because they're > functionality which is core to the system that any D program is running on. Once upon a time, there was a D runtime library (unrelated to Druntime) that has no C library dependence at all. It was an interesting idea, but I don't know that there's any system that D targets which doesn't support C.