Does D have too many features?

[Alex Rønne Petersen]

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