Thread overview
std.prelude vs core library
Jan 16, 2014
Ross Hays
Jan 17, 2014
Rikki Cattermole
Jan 17, 2014
Kagamin
Jan 17, 2014
Sean Kelly
January 16, 2014
I was reading about Rust and one thing that caught my attention as interesting was the inclusion of std::prelude in the beginning of every package. I was curious what the advantage of this were versus having things declared in object.d for what seems to be the same effect.

Also after looking at the source code of Rust on Github, I don't see anything in the runtime that mirrors the D core.* modules. I know that it isn't required to be there, but I am just curious why D took the approach of having some core modules in the runtime? Is it just so Phobos doesn't need ported in order for D to be ported to a new system?

Sorry if these questions seem a bit out there, just trying to learn some more about programming languages design/implementation.

Thanks,

Ross
January 17, 2014
On Thursday, 16 January 2014 at 19:54:45 UTC, Ross Hays wrote:
> I was reading about Rust and one thing that caught my attention as interesting was the inclusion of std::prelude in the beginning of every package. I was curious what the advantage of this were versus having things declared in object.d for what seems to be the same effect.
>
> Also after looking at the source code of Rust on Github, I don't see anything in the runtime that mirrors the D core.* modules. I know that it isn't required to be there, but I am just curious why D took the approach of having some core modules in the runtime? Is it just so Phobos doesn't need ported in order for D to be ported to a new system?
>
> Sorry if these questions seem a bit out there, just trying to learn some more about programming languages design/implementation.
>
> Thanks,
>
> Ross

There is two libraries that go along with D by default. Druntime and Phobos.
Druntime's job is to make D work on a platform. This includes the garbage collector and basic types.

The core package you are referring to is provided by druntime[0]. Basically any common function that requires underlying interaction should occur here, by my understanding. Example, threading.

Where as phobos[1] does not contain any core functionality. Only helper types/functions to make things easy and hopefully idiomatic D style.

The documentation on the site may have it generated together i.e. the menu's but they are not together in repository and linking side of things.

[0] https://github.com/D-Programming-Language/druntime/tree/master/src/core
[1] https://github.com/D-Programming-Language/phobos/tree/master/std
January 17, 2014
Initially druntime was a part of phobos, and tango was an alternative implementation of standard library, and you couldn't use phobos and tango in one application, that's why druntime was extracted as common base library for tango and phobos.
January 17, 2014
Another small reason is to enforce decoupling between required code and the rest of the library. Back when Phobos was all one library, half the library was compiled into every program. The runtime writes to stderr, the IO package relies on other modules...  Kind of like what happens now if you import std.stdio. And while this can be accomplished via deliberate effort towards decoupling. But that's really hard to accomplish in an open source project.  Functionally, think of core as being similar to java.lang.