On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu wrote:

I don't understand the objection. Are you arguing that we shouldn't make core.stdc and core.stdcpp available, and instead let anyone who wants to use libc and libc++ write their own declarations?

No. We currently have std.c and core.stdc. I believe core.stdc should be migrated to std.c, not the other way around. And before we make the same mistake with core.stdcpp, we should set a new precedent with std.cpp instead.

"Why?" D is not subset of C. D is not defined in C. It is its own autonomous language (at least I though it was). Therefore, the dependencies on libc are artificial. Let's not add another artificial dependency with core.stdcpp. The OS bindings in core.sys are another artificial dependency, but let's not go there right now.

"But druntime relies on libc?" Wrong! Some of the code needed to port druntime to certain platforms relies on libc (and actually doesn't need to). This code should be encapsulated and isolated from other ports, not publicly exposed and conflated with the rest of the language implementation. This is in the spirit of issue 11666.

I believe druntime's scope should be reduced to simply implementing the language, not creating an OS or library API. That's what phobos and DUB are for.

I'm asking this community to consider setting a new precedent for druntime: reduce the scope to just the language implementation, encapsulate and isolate the platform specific logic (e.g. the ports - see 11666), and deport the artificial dependencies to phobos or other libraries.


Reply via email to