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 things start to get weird. Please let me know if you have a solution to
this problem.

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 implementation.

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.


Reply via email to