core.traits?

[Jonathan M Davis]

On Monday, January 7, 2019 3:10:02 PM MST H. S. Teoh via Digitalmars-d 
wrote:
> On Mon, Jan 07, 2019 at 04:54:15PM -0500, Steven Schveighoffer via 
Digitalmars-d wrote:
> > On 1/7/19 4:41 PM, H. S. Teoh wrote:
> > > On Mon, Jan 07, 2019 at 01:25:17PM -0800, Manu via Digitalmars-d
> > > wrote:
> > > [...]
> > >
> > > > Perhaps AliasSeq should live somewhere different?  I'm feeling
> > > > like a lean/trimmed-down core.meta might want to exist next to
> > > > core.traits though; it seems reasonable.
> > >
> > > I'm afraid this would set the wrong precedent -- since there's
> > > core.traits for std.traits and core.meta for std.meta, why not also
> > > have core.typecons, core.range, and then it's all gonna go downhill
> > > from there, and before you know it there's gonna be core.stdio and
> > > core.format... *shudder*
> >
> > std.internal.traits contains pieces of std.meta -- a quick look shows
> > it has AliasSeq (but under the name TypeTuple),
>
> What, wut...?  `TypeTuple` still exists?! I thought we had gone through
> a somewhat painful deprecation cycle just to kill it off. Or is that
> cycle not done yet...?

We're talking about druntime internals here. TypeTuple was one of the things
that got copied into druntime as internal. It was later renamed to AliasSeq
in Phobos, but the copied stuff in druntime didn't necessarily get changed,
since it was all internal and had nothing to do with the Phobos stuff it
originated from.

> > allSatisfy, anySatisfy, Filter, staticMap. We might as well just move
> > the whole thing there.
>
> I dunno, IMO allSatisfy, anySatisfy, and esp. Filter and staticMap are
> all heavy-weight templates (not in terms of code complexity, but in the
> sheer amount of templates that will get instantiated when you use them,
> AKA compiler slowdown fuel).  I'm not so sure they should go into
> druntime.

Historically, we've tried to only put stuff in druntime that needs to be in
druntime for druntime to do what it does. That does sometimes get stretched
(e.g. we put all of the OS bindings in druntime rather than just the ones
that druntime needs), but Phobos is the standard library, not druntime.
druntime is the runtime. If something needs to be there so that the runtime
can do its thing, then we put it in druntime, but not much else should be
there. Certainly, anything that is there needs to be stuff that's actually
core. So, in that respect, it's pretty questionable to move all of
std.traits and std.meta into druntime wholesale.

What we had for a while was traits just being copied into druntime where
they were needed, resulting in duplicate implementations in various places
(especially for TypeTuple). Later, they were largely consolidated into
core.internal.traits, but they were still completely separate from Phobos.
More recently, the traits in core.internal.traits have had their std.traits
implementations turned into simple wrappers that use the core.traits symbols
(they're not aliased, because that doesn't work well with the documentation,
so you get an extra layer of template with every trait whose implementation
is in druntime).

So, if Manu needs a trait for something in druntime, the normal thing to do
at this point would be to just add it to core.internal.traits and then
potentially make Phobos wrap the druntime symbol. We don't actually need to
move anything wholesale, nor do we need something like core.traits which is
intended to make the traits publicly available from druntime.

Another issue here if you actually look at core.traits and std.meta is that
there are actually several templates which use other pieces of Phobos. e.g.
isInputRange gets used in std.meta.aliasSeqOf as does std.array.array, and
std.traits.packageName uses startsWith. So, while many of the templates from
std.traits and std.meta could be moved, actually trying to move them all
wouldn't actually work without reimplementing yet other pieces of Phobos.

Personally, I think that the only real benefit of having something like
core.traits over having core.internal.traits is that you can move the
documentation for those symbols to their druntime implementations and make
the Phobos implementations actual aliases with just a link to the druntime
documentation instead of needing a thin wrapper template. Anyone wanting to
avoid Phobos can still use those traits from std.traits and std.meta just
fine, since it wouldn't involve linking against Phobos, just importing the
module (even some of the traits that we can't move would work just fine,
because they'd just be pulling in other Phobos symbols that don't involve
linking). But it does get pretty weird to have some of the traits in core
and some in std with no real obvious distinction, since it's based on what
druntime needs. So, in that respect, keeping them internal is cleaner.

Either way, I think that it's quite clear that we can't move everything.

- Jonathan M Davis