On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote:
"Mike" wrote in message
What's the motivation for embedding these things in the d
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
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 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.