core.stdcpp

[Sean Kelly via Digitalmars-d-announce]

On Wednesday, 27 August 2014 at 21:38:04 UTC, deadalnix wrote:
>
> The problem is that you don't always want to bring libc and 
> libstdc++ with you with every single project you write.
>
> Thus it shouldn't be in the runtime (except the very bit you 
> can't get rid of). It can still be core.stdc .

To be fair, the only part you bring with you are the dependencies
that Druntime itself has.  And nearly all of core.stdc is
declarations anyway, so the only code bloat is unused ModuleInfo
objects (notice that in places where Druntime uses C structs it
declares them as "=void" to avoid depending on default
initialization).

The remaining issue becomes one of maintenance.  If Druntime only
declares the functions it needs, then where does the other stuff
live?  If you want to use that other library to get everything,
does it publicly import core.stdc for the basics?  What if
Druntime needs a new call for some reason that's in this separate
library?  Do we declare it in core.stdc and cause collisions?
What if D is ported to a new platform?  That may require a whole
raft of new declarations, both in a common API like core.stdc and
in something more targeted like core.sys.linux.

Don't get me wrong, I hate having to maintain the modules in
core.stdc and core.sys.  It's the worst job ever.  I'm just not
aware of a better solution to this particular problem.