On Friday, 29 August 2014 at 16:37:12 UTC, Sean Kelly wrote:
On Wednesday, 27 August 2014 at 04:23:28 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote:
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.
Please understand that I'm not suggesting we start refactoring
druntime for 2.067. All I'm asking for is that we recognize
that C/C++ library and OS bindings don't belong in druntime as
public modules, and we gradually work towards migrating them
to phobos or some other library in the years to come.
The reason these are in Druntime at all is because code in
Druntime depends on them. So if they were split into a separate
library then it would be a required library. And even if we
completely eliminate any dependency on standard C functions, I
don't see any way to avoid depending on platform-specific calls.
Now I would be fine with including just a subset of declarations
in Druntime (which is really what we have right now anyway), but
if the remainder were split into a standalone library then
start to get weird. Please let me know if you have a solution
I'm not suggesting we eliminate libc and platform-specific
bindings, just encapsulate and isolate them.
To make D work on any platform, druntime must be ported to that
platform. To do the port, of course we have to make
platform-specific calls. That's no problem. But they should be
internally encapsulated in that port's logic, not publicly
exposed. And if we implement 11666 we should isolate each port
to its own folder so the abstraction between language and
platform is clear.
For example (what druntime may look like many years from now):
If a port chooses to use libc, no problem. Just encapsulate the
bindings in its own file/folder. Don't make it publicly
available. If D programmers want bindings to libc in their
programs, they should use std.c in phobos (or we could simply
move core.stdc to phobos).
This means that we may have duplicate bindings in druntime and
std.c for the few features of libc that are required to implement
the port. This isn't really a duplication of code as it should
just be type declarations and function signatures - just
information for the linker.
Some time in the future, many years from now, it would be nice if
gradually those C bindings were replaced with D implementations
to throw out the middle-man and put the port directly on the
platform. There's absolutely no hurry, and if it's never done,
so be it.
Now what about the stuff in core.sys.whateverOS? It's the same
thing. Certainly these are needed to port druntime to a given
platform, but they are an implementation detail of the port, not
the language. Again they should be encapsulated and isolated.
If users want to make calls to whateverOS libs, than we can
either move core.sys.whateverOS to phobos, or create a new
namespace std.whateverOS or whatever namespace name you want, and
users can use that. Just get it out of the way of the language
But NONE of this needs to be done right now, or even this year,
or even next year. All I'm asking for with this thread is that
instead of making it harder to move away from the current
structure by adding core.stdcpp to druntime, we simply choose to
put the C++ standard library bindings in std.cpp in phobos. Or
you could choose to keep it as core.stdcpp, but just put it in
phobos instead of druntime.
The C++ standard library bindings don't exist yet. There's
nothing to change. It's just a design decision. What do you
want druntime to look like in 10 years? Let's make sure we're
pointed in that direction with the C++ standard library bindings.