On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote:
"Mike" wrote in message news:sdrjfagsayomsngme...@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.


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

Reply via email to