On 08-05-2012 23:31, Jonathan M Davis wrote:
On Tuesday, May 08, 2012 14:17:14 Sean Kelly wrote:
On May 8, 2012, at 9:35 AM, foobar wrote:
On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote:
On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote:
[...], what if I find it useful to use e.g. FORTRAN code, should the
relevant functions also be in the stdlib?>>
No, FORTRAN has absolutely nothing to do with D. C, on the other hand,
does. Both druntime and Phobos depend heavily on the C stdlib. The GC
uses malloc/free, std.stdio.File is a wrapper around FILE*, etc.>
Irrelevant. For all I care druntime could be implemented in Klingon. That
doesn't mean its API needs to include Klingon as well. That's called
"encapsulation".
This is difficult to do with the module system. You'd have to hand-craft
.di files with the stdc headers left out to avoid bundling them in the
distro. They could go into core.internal I suppose though.

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.

+1. We have better things to fix.


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 do think we could benefit from hiding the (deprecated) std.c.* modules on dlang.org (I posted about this a while back).


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.

- Jonathan M Davis

--
- Alex

Reply via email to