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?
