Does D have too many features?

[Sean Kelly]

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.