On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu
I don't understand the objection. Are you arguing that we
shouldn't make core.stdc and core.stdcpp available, and instead
let anyone who wants to use libc and libc++ write their own
No. We currently have std.c and core.stdc. I believe core.stdc
should be migrated to std.c, not the other way around. And
before we make the same mistake with core.stdcpp, we should set a
new precedent with std.cpp instead.
"Why?" D is not subset of C. D is not defined in C. It is its
own autonomous language (at least I though it was). Therefore,
the dependencies on libc are artificial. Let's not add another
artificial dependency with core.stdcpp. The OS bindings in
core.sys are another artificial dependency, but let's not go
there right now.
"But druntime relies on libc?" Wrong! Some of the code needed to
port druntime to certain platforms relies on libc (and actually
doesn't need to). This code should be encapsulated and isolated
from other ports, not publicly exposed and conflated with the
rest of the language implementation. This is in the spirit of
I believe druntime's scope should be reduced to simply
implementing the language, not creating an OS or library API.
That's what phobos and DUB are for.
I'm asking this community to consider setting a new precedent for
druntime: reduce the scope to just the language implementation,
encapsulate and isolate the platform specific logic (e.g. the
ports - see 11666), and deport the artificial dependencies to
phobos or other libraries.