"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[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?

Reply via email to