"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.
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.
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.