Does D have too many features?

[Alex Rønne Petersen]

On 08-05-2012 23:48, Sean Kelly wrote:
> 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.
>

I just hope none of it goes away. I make extensive use of many core.* 
modules.

>
>> 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.

*Is* there any system that doesn't support C? ;)

-- 
- Alex