"Mike" wrote in message news:zjscnxerhbxnopvay...@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 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
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
??????????? 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?