core.stdcpp

[Mike via Digitalmars-d-announce]

On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote:
> "Mike"  wrote in message 
> news:sdrjfagsayomsngmeywp at forum.dlang.org...
>
>> What's the motivation for embedding these things in the d 
>> runtime?
>
> Make them available.
>
>> Wouldn't it be better to have a libc_d instead of core.stdc, 
>> libcpp_d instead of core.stdcpp, liblinux_d instead of 
>> core.sys.linux, etc...?
>
> I don't see how.

The C standard library and C++ standard library are not part of 
D-the-language.  D would even be better served by putting these 
features in phobos as std.stdc and std.stdcpp.  This would make 
them just as conveniently available to users, and reduce the 
coupling between the language and the platform.

>> I thought the D runtime was supposed to be simply an 
>> implementation of the language features, but it appears its 
>> scope is much more broad.
>
> Language features (gc, profiler, etc), OS bindings, C stdlib 
> bindings.  C++ bindings aren't a big leap from there.
>
> I think druntime started off including OS and stdlib bindings 
> because it needed to use them internally, and it made more 
> sense to expose them publically instead of adding dependencies 
> or duplicating them.

I think this is what makes issue 11666[1] so difficult and 
controversial.  The features of the C std lib that are needed by 
the D runtime are not many, and could be re-implemented in D. The 
OS bindings needed to implement the D runtime could be internal 
and moved to a separate folder as proposed in the spirit of 
11666.  Public OS bindings could be put in std.linux, 
std.windows, etc... along with std.stdc and std.stdcpp.

It might be expeditious to just wrap and link, but I argue that D 
would be more appealing as a language (rather than a framework) 
if this wasn't the case.

>> This makes the language coupled to those platforms and less 
>> general purpose like C and C++.
>
> I disagree.  D does not depend on C++ being available, but 
> druntime should provide bindings if possible.  Depending on the 
> C runtime is not a problem, because realistically you will 
> either have a C runtime available for your platform, or be on a 
> restricted platform where you will need to define your own D 
> runtime, and can choose which parts of the C runtime to include.

I concede this is true for the vast majority of systems out 
there, but it makes D an applications programming framework, not 
a systems programming language.

I politely ask those pursuing core.stdcpp to reconsider and look 
further in the future.  Please think beyond desktop and server 
application programming.  Consider what D could be used for, not 
just what it is currently used for, and darken the line between 
the language and the platform.  Make it a more of a language, and 
less of a framework.

Mike

[1] https://issues.dlang.org/show_bug.cgi?id=11666