core.traits?

[Manu]

On Mon, Jan 7, 2019 at 2:10 PM H. S. Teoh via Digitalmars-d
<digitalmars-d at puremagic.com> 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...?
>
>
> > 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).

Ummm, well, yes and no. staticMap is DEFINITELY like you say, one of
the worst, and I really think it needs a language solution.
C++'s `...` expression is exactly staticMap, and I wonder if we need
an expression like that in-language to take load off staticMap,
because it's perhaps one of the slowest parts f the language.
We can translate almost anything to CTFE, *except* code that invokes
staticMap, so I really reckon it needs a language tool.

This is an aside, if we wanna talk about staticMap, we should start a
new thread.

> I'm not so sure they should go into druntime.

Then you're kinda making a case that NONE of it should go in druntime,
because they're such common building blocks.
Also, you've already lost the game, because they're already in
druntime (in core.internal).

> > The fear of moving other pieces is real, but only if you look
> > superficially.  traits and meta are really part of the language, I
> > can't imagine using D without it (and neither can any of the people
> > who put pieces of those modules into druntime).
>
> Actually, I find myself redefining AliasSeq locally with a shorter name
> all the time.  Scarily enough, doing that is shorter than typing `import
> std.traits : AliasSeq;`.

I've been known to do that too... I could do that for core.traits
aswell, but that seems pretty lame.

> > I don't want to see anything more complex and interdependent get
> > sucked in.  I know the goal for Manu right now is emplace, which does
> > feel like a language feature. But as has been said many times here,
> > std.traits is a no-brainer, and std.meta is really a building block
> > that std.traits uses.
> [...]
>
> Wait, so you're saying we should move the *entire* std.meta and
> std.traits to druntime...?

I'd like to be more selective than that; at very least, audit every
single symbol coming across. But some part of me thinks this may
actually be a very reasonable proposal...