On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote:
On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote:
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote:


The irony is D1 has std.c, and for D2 it was migrated to core.stdc.

...and design takes the backseat to convenience.

This was a necessary part of the separation of the runtime
components of the standard library from the extraneous stuff.
Consider Druntime to be roughly equivalent to the java.lang
package.  It contains code and interfaces that pertain to the
language definition, plus certain related low-level functionality.

I don't believe it was necessary. D is quite capable of implementing the same logic that libc has. However, if for convenience, expediency, time-tested-reliance, optimization, or some other reason, one wishes to use libc, they can encapsulate it in the platform-specific logic, because that's what it is.


It will always be a judgement call for where to draw the line.
For example, should Range be in Druntime since it's something the
compiler is aware of?  What about basic math routines that the
compiler might replace with an intrinsic call?  So far, we've
actually erred on the side of having less in Druntime rather than
more.  It currently contains user-visible code that's actually
required for every D application: the GC, threads, bit
operations, and atomics, plus some additional code and
declarations that are required to implement these features.  And
that's it.

If D is defined as a garbage-collected language, then it makes sense for the GC to be in druntime. If D is defined as a language the intrinsically supports threads, then that belongs in druntime, etc...

But D is not defined as a superset of libc, or a standard operating system API, so there is no reason to publicly expose these.

My argument can be limited to core.stdc/stdcpp for now.
* Only a very limited subset of libc is needed by druntime
* These can be eliminated by implementing them in D, or by using what the platform provides (kernel libs, etc...). It may not be convenient/expedient to do so, and will take significant effort and testing, but I'm not saying it needs to be done right now, just that it should be a goal. * If it is decided to keep them for convenience/expediency or another reason, they can be encapsulated by the ports that need them rather than publicly exposed.

D could be so much more than what it currently is. What I eventually would like to see is the following ports:

Architecture (bare metal) ports:
-------------------------------
X86
X86_64
ARM9
ARM7M
MIPS
etc..

OS Ports
--------
Windows
Posix
Linux
MacOS
etc...

I believe that list shows what a narrow focus D currently has.

While a libc exists for all of these, and it might be convenient to use it, it is not necessary given D's capabilities. D could do it all, and I think that would set D apart from many other languages if it did.

That being said, it certainly would be convenient to make use of libc for many of these ports, so let's use it. Just encapsulate it so if, in the future, someone like me wants to submit pull requests to gradually remove the dependency on libc, they can do so without breaking the API and causing controversy.


You might argue that Druntime shouldn't exist as a separate
library at all, and at times I've wondered this myself, but some
of the reasons for this have really borne out in practice, such
as the forced elimination of unnecessary dependencies.  If you
look at D1 you'll find that the better part of the standard
library is linked with every D application because some stuff
that's always included (the GC code and what's in dmain, for
example) uses high-level code which in turn depends on everything
else.  And while it's possible to avoid this with proper
discipline, this is much easier to accomplish if the code simply
isn't available in the first place.

I think it is good design to separate the implementation of the language spec and compiler intrinsics from library functions that implement domain-specific logic or commonly used utility functions even if they are considered "low-level".

If one thinks of druntime as a low-level library, there's no reason to separate it from phobos. But if it's thought of as the language implementation, as I do, then the reason to separate the two is quite apparent, and the boundary between the two is quite stark.


When making these arguments, please try thinking about the
library from the perspective of a library designer and not an end
user.  Does the standard C interface truly belong in Phobos?  In
Druntime?  Elsewhere?  Why?  And what factors might influence
your decision? Are any of these factors currently present? Some
of the reasons for the current design are historic and
unnecessary and others are not.  And anything can be changed if
someone comes up with a better idea and is willing to do the work
to make it so.  It sounds like maybe you have a better idea so
why not submit a pull request demonstrating the solution?

I do have what I believe to be a better solution, and I believe I have articulated it, but it needs community support to go anywhere.

I must have a different view of druntime than the rest of this community. I believe it should be an implementation of the language spec, compiler intrinsics, and encapsulated/isolated platform-specific logic. I don't see it as a low-level library. Low-level libraries are just another namespace in phobos. I don't see how one can even define a "low-level library" and that is probably why the line between phobos and druntime looks so blurry to some.

In this thread, I'm simply trying to avoid having core.stdcpp thrown in the druntime when I'm trying to move core.stdc to std.c.

It is wise to first use these forums to check for support first, before much time and energy is spent on work that will just be rejected. Take a look at all the work that went into DIP62 and how that worked out for the author.

I'm judging by both the responses in this thread and the lack of responses in this thread that there isn't support, so I'm fine to go my own way with my ideas if that's what's preferred.

Mike

Reply via email to