core.stdcpp

[Daniel Murphy via Digitalmars-d-announce]

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

> The C standard library and C++ standard library are not part of 
> D-the-language.  D would even be better served by putting these features 
> in phobos as std.stdc and std.stdcpp.  This would make them just as 
> conveniently available to users, and reduce the coupling between the 
> language and the platform.

I really don't see a practical problem with having them in druntime, only a 
philosophical one.  They should still be available when not using phobos, 
and they are used in druntime internally.

> I think this is what makes issue 11666[1] so difficult and controversial. 
> The features of the C std lib that are needed by the D runtime are not 
> many, and could be re-implemented in D. The OS bindings needed to 
> implement the D runtime could be internal and moved to a separate folder 
> as proposed in the spirit of 11666.  Public OS bindings could be put in 
> std.linux, std.windows, etc... along with std.stdc and std.stdcpp.

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.

> It might be expeditious to just wrap and link, but I argue that D would be 
> more appealing as a language (rather than a framework) if this wasn't the 
> case.

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)

> I concede this is true for the vast majority of systems out there, but it 
> makes D an applications programming framework, not a systems programming 
> language.

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

> I politely ask those pursuing core.stdcpp to reconsider and look further 
> in the future.  Please think beyond desktop and server application 
> programming.  Consider what D could be used for, not just what it is 
> currently used for, and darken the line between the language and the 
> platform.  Make it a more of a language, and less of a framework.

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?