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