On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote:

The irony is D1 has std.c, and for D2 it was migrated to core.stdc.

...and design takes the backseat to convenience.

This was a necessary part of the separation of the runtime
components of the standard library from the extraneous stuff.
Consider Druntime to be roughly equivalent to the java.lang
package.  It contains code and interfaces that pertain to the
language definition, plus certain related low-level functionality.

It will always be a judgement call for where to draw the line.
For example, should Range be in Druntime since it's something the
compiler is aware of?  What about basic math routines that the
compiler might replace with an intrinsic call?  So far, we've
actually erred on the side of having less in Druntime rather than
more.  It currently contains user-visible code that's actually
required for every D application: the GC, threads, bit
operations, and atomics, plus some additional code and
declarations that are required to implement these features.  And
that's it.

You might argue that Druntime shouldn't exist as a separate
library at all, and at times I've wondered this myself, but some
of the reasons for this have really borne out in practice, such
as the forced elimination of unnecessary dependencies.  If you
look at D1 you'll find that the better part of the standard
library is linked with every D application because some stuff
that's always included (the GC code and what's in dmain, for
example) uses high-level code which in turn depends on everything
else.  And while it's possible to avoid this with proper
discipline, this is much easier to accomplish if the code simply
isn't available in the first place.

When making these arguments, please try thinking about the
library from the perspective of a library designer and not an end
user.  Does the standard C interface truly belong in Phobos?  In
Druntime?  Elsewhere?  Why?  And what factors might influence
your decision?  Are any of these factors currently present?  Some
of the reasons for the current design are historic and
unnecessary and others are not.  And anything can be changed if
someone comes up with a better idea and is willing to do the work
to make it so.  It sounds like maybe you have a better idea so
why not submit a pull request demonstrating the solution?

Reply via email to