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.
