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