Does D have too many features?

[foobar]

On Wednesday, 9 May 2012 at 08:16:35 UTC, Alex Rønne Petersen 
wrote:
>>
>> 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.
>

Could you please provide more details about your use-cases?
As Sean said, it might indicate missing functionality in Phobos.
Keep in mind we were specifically discussing the C APIs which are 
an external dependency. No one suggests removing the low-level 
druntime APIs such as GC hooks.

>> 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? ;)

It isn't only a question of whether the system supports C or not. 
There are many considerations when choosing your tool-chain. For 
instance, the reference implementation of some languages is 
implemented in ML for its correctness properties. EcmaScript for 
instance uses ML for the language/runtime.
In the JS case, it doesn't necessarily mean your browser will run 
ML, it just means the highly optimized vendor implementation has 
an official correct version to compare to.

In the D world, we have a few projects that aim to implement a D 
compiler using D. Why would such a compiler/runtime need to 
provide C APIs if it's completely written in D?