core.stdcpp

[Mike via Digitalmars-d-announce]

On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu 
wrote:

> 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 
> declarations?

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 
issue 11666.

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.

Mike