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.


Reply via email to