Does D have too many features?

[Don Clugston]

On 09/05/12 10:16, Alex Rønne Petersen wrote:
> 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? ;)

There are plenty of systems that don't support C99 perfectly.