core.stdcpp

[Mike via Digitalmars-d-announce]

On Tuesday, 26 August 2014 at 12:54:49 UTC, Daniel Murphy wrote:

> I really don't see a practical problem with having them in 
> druntime, only a philosophical one.

It give the impression that D requires the C standard library, 
the C++ standard library, and an full-featured desktop OS in 
order to function.  If I create a port without core.stdc, it can 
be argued that my port is incomplete.  Well I argue that my port 
is a complete implementation of the language and core.stdc is not 
part of the D language.

> They should still be available when not using phobos,

Then they can be put in their own library instead of phobos.  
That's even better as far as I'm concerned.  GTKD isn't part of 
phobos or druntime.  I don't see libc as being any different (in 
principle) than GTKD.

> and they are used in druntime internally.

For a practical implementation, those ports that have a libc can 
make use of it, but it should be internal, and isolated from the 
language implementation and the other ports, as is the spirit of 
11666.

But you could take it a step further for the principled approach. 
  Implement those few features of libc that are needed by the 
druntime in D, and earn some bragging rights.

Why create DDMD?  We already have an implementation in C++, 
right.  What a waste of time... (of course I'm being facetious.  
Forgive me, but I think it's a great example of why we should do 
something in D even though a C/C++ implementation exists.  No 
offense intended)

> 11666 is contentious because everybody has a different opinion 
> on the layout.  This is about personal preferences, and has 
> nothing to do with OS bindings being in druntime.  The same 
> exact discussion would happen if they were in phobos.

That's exactly my point.  The debate that ensued with 11666 had 
nothing to do with the spirit of 11666.  If those OS bindings 
weren't in druntime, 11666 would already be implemented without 
controversy.  And we'd likely already have a few more ports of D 
to other platforms.  The 11666 debate belongs in a std.linux 
debate or a liblinux debate or some other OS API port debate.

Publicly exposing core.stdc and the OS bindings in druntime is 
getting in the way of bringing D to more platforms, and the 11666 
debate demonstrates that.

> I get that you're saying this, but why?  How will it make any 
> difference to anything ever?  libc is ubiquitous, and the parts 
> that are used internally could trivially be reimplemented on a 
> platform where it was missing.  (or more likely, it could just 
> be ported)

Or those features in libc could be implemented in D, removing the 
artificial dependency on libc.

> ???????????  If you want to / need to, you can write a libc 
> implementation in D.  The fact that the major D platforms all 
> choose to link against the system libc instead of rolling their 
> own has no bearing on the language class of D.  The fact that 
> druntime includes a prototype for memcpy or fopen does not 
> change anything either.  It just makes D more convenient for 
> porting C code.

Only the *port* should have bindings to libc.  The language 
implementation should not.  Again those bindings should be 
encapsulated in the port, not publicly exposed as part of the D 
language.

> It could be my failing, but I really don't see the point.  What 
> are the potential consequences of maintaining and extending the 
> C, C++ and OS bindings in druntime?

* It conflates the language with the platform.  druntime should 
be solely the implementation of the language, not an OS API.
* It conflates the implementation of the language with bindings 
for external libraries. Again, druntime is the language 
implementation, not an application programming framework.
* It sets the wrong precedent for a systems programming language. 
  IMO a true systems programming language should be self-reliant.  
That is, it should be a language that can be used to build the 
first layer of hardware abstraction.
* It creates artificial dependencies when there's no real 
dependency.  C++ being a superset of C is an example of a real 
dependency.  That is not D.
* It gets in the way of porting the language to more platforms 
and complicates maintenance of the runtime. Case in point: the 
11666 debate.
* It makes D unportable to some platforms without creating their 
own dialect of the language or their own D runtime implementation

In summary, I believe libc, libstd++, and the OS bindings should 
be encapsulated and isolated by the ports that need them, not 
publicly exposed as part of the D language implementation.  
Having bindings to these these libraries is super important, and 
I'm glad they exists.  I just don't think they belong in the D 
language implementation, except as encapsulated, isolated 
artifacts of ports that need them.

Mike