core.stdcpp

[Mike via Digitalmars-d-announce]

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.

Mike