core.stdcpp

[Daniel Murphy via Digitalmars-d-announce]

"Mike"  wrote in message news:bkkdiikafdsraqssjndv at forum.dlang.org...

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

What platform supports threads and GC but doesn't have a C lib available?  I 
certainly would argue that this hypothetical port is incomplete, not because 
druntime including bindings to libc declares it part of the language, but 
because I can't see a good reason not to include them.

> Then they can be put in their own library instead of phobos.

Yes, they could.  IMO the downsides of having to maintain a third library 
outweighs the 'correctness' advantage, or even having a different root 
package for this stuff.  And there is no way it's ever going to change at 
this point.

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

Druntime doesn't use GTK, so it is different.  The inclusion of C/OS 
bindings is historical, and not worth changing.

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

There is no point as the bindings are already in druntime and there is very 
little chance that is going to change.

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

You could, but it has very little practical value.  I personally wouldn't 
waste my time bragging to someone who thinks druntime depending on libc is 
an argument against D.

> 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)

It's possible you missed the point of DDMD.  DMD is an actively developed 
codebase which can benefit from many of the features D offers.  Well, that 
was my motivation anyway.  I know other people got excited by the idea for 
other reasons.

There is no practical advantage (to the project) from converting a fully 
debugged, optimized application or library to another language, unless the 
language barrier is preventing interop.  A libc written in D would not give 
us anything of practical value.

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

No, the exact same thing would have happened if they were in a different 
package/repository.  A different root package would not change the 
contributors or contribution process.

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

This is just nonsense.  Changing the root package changes nothing.

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

Re-implementing debugged and optimized code is a waste of time.

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

1) Being part of druntime does not automatically mean something HAS to be 
available on every platform.  eg the windows bindings are not available on 
non-windows
2) I don't see any point in not exposing the c lib from druntime, nor do I 
see any platform where that would be a problem that does not have much more 
serious issues with hosting D.

> * It conflates the language with the platform. druntime should be solely 
> the implementation of the language, not an OS API.

I disagree, having the OS API in druntime is great and not a problem.

> * It conflates the implementation of the language with bindings for 
> external libraries.

C interop is part of D.  Low level (direct) access to operating system APIs 
is part of D.  Exposing them is useful.

> Again, druntime is the language implementation, not an application 
> programming framework.

By this logic the C lib header files and windows.h files make 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.

D can be used for that.  But realistically, this is a constrained 
environment which will use a custom druntime, and be restricted to a subset 
of D.

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

I don't consider this to be a problem worth worrying about.

> * It gets in the way of porting the language to more platforms and 
> complicates maintenance of the runtime. Case in point: the 11666 debate.

No, it doesn't.  Even if these bindings weren't in druntime, they'd be in 
another official library.  Nothing would be different with respect to 11666.

> * It makes D unportable to some platforms without creating their own 
> dialect of the language or their own D runtime implementation

I expect D is already unportable to these platforms without doing these 
things.  Removing libc bindings would not change this.

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

In an ideal world, the bindings would be more cleanly separated from other 
runtime stuff.  But they're not.  It would require a very compelling 
argument to move them now, and this really isn't it.

We could document that core.stdc is not a required part of a D 
implementation, but it should be trivial to provide on any platform that can 
support a complete the rest of D, so there doesn't seem to be any point.