www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Uniting library traits

reply Eduard Staniloiu <edi33416 gmail.com> writes:
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
Nov 12 2018
next sibling parent Neia Neutuladh <neia ikeran.org> writes:
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.
Nov 12 2018
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Nov 12 2018
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
 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.
Nov 14 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Nov 14 2018