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.

Kind regards,
Edi

core.internal.traits is an internal module containing a minimal set of reflection functions that are required in the runtime. The runtime is the minimal set of code required for all language features to work as the spec requires.

Since a lot of stuff in std.traits isn't necessary to make the language work, it doesn't belong in druntime.

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

> 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

What about the docs? Should doc generation merge in public import docs? Seem generally useful.

On Wednesday, November 14, 2018 7:54:12 AM MST Jesse Phillips via Digitalmars-d wrote:
> > 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
>
> What about the docs? Should doc generation merge in public import docs? Seem generally useful.

The documentation should just go in Phobos in this case, since the traits aren't intended to be part of druntime's public API. They're in core.internal.

As for copying documentation with a public import in general, I'm inclined to argue that it's better to just point to the original documentation. Links in the documentation could easily have been written to be local to the module that they were in, breaking them if the documentation is copied. Similarly, the description could become confusing if it assumes that it's in a particular module when it isn't. Linking to the original description puts you in the correct context when reading the it, whereas copying it does not.

Another interesting quirk of description that I hadn't thought of that was taken into account with the recent PR to consolidate the implementation of Unqual was that the description talked about T, and while Unqual has T when defined as a template, a public import would not. So, core.internal.traits.Unqual was privately imported as a renamed import of CoreUnqual and then wrapped with a thin template named Unqual which simply instantiated CoreUnqual just so that the declaration in the documentation would have T in it, and the documentation would make sense when talking about T, which it wouldn't have if it had been a public import or alias.

- Jonathan M Davis