Uniting library traits

Jonathan M Davis newsgroup.d at jmdavisprog.com
Tue Nov 13 04:23:17 UTC 2018

On Monday, November 12, 2018 3:37:48 PM MST Eduard Staniloiu via 
Digitalmars-d wrote:
> Cheers everyone!
> I have a question that popped in to my head due to the fact that
> we have `traits` written into both druntime and Phobos.
> In druntime, we have the `core.internal.traits` module, which has
> quite a few traits copied form Phobos' `std.traits`.
> Would it be a bad idea to move `std.traits` and probably
> `std.meta` into druntime?
> What is the rationale (preferably with pros and cons) of keeping
> them split across libraries?
> In my humble opinion, I think those should reside in druntime as
> then they would be accessible to a larger chunk of library code.

druntime is not the standard library. It's the runtime, and it's supposed to
be small. It only has stuff like the traits in core.internal.traits in
there, because it turned out that it needed to have them. It does make sense
to consolidate those implementations and have Phobos reuse the
implementations from druntime, but IMHO, it really does not make sense to
start putting standard library stuff in druntime for public consumption
unless it actually needs to be there. Most of std.traits does not need to be
in druntime, and druntime only duplicates a small fraction of what's in
std.traits and std.meta. Also, just about every time we put something in
druntime instead of Phobos, it confuses people about where it is.

So, if it turns out that a particular trait is needed by druntime, it does
make some sense to move its implementation to druntime, and then have
std.traits publicly import it, but from the public API perspective, it
should still be in Phobos, and I don't think that we should be trying to
move all of the traits into druntime - just those few that we find that are
actually needed there.

- Jonathan M Davis

More information about the Digitalmars-d mailing list