core.traits?

Steven Schveighoffer schveiguy at gmail.com
Mon Jan 7 22:26:15 UTC 2019


On 1/7/19 5:10 PM, H. S. Teoh 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...?

It's an internal definition, so it can be anything it wants it to be. It 
could be Tuple or Foobar.

> 
> 
>> 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.

Again, they are already there, and for a reason.

>> 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;`.

The point is to have it universally recognized construct. When your 
code's documentation says `TList` or whatever, then someone has to go 
figure that out. If it says `AliasSeq`, it's known what it is.

>> 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...?

At least std.meta. std.traits can possibly be split into critical 
language-enabling traits and the less important ones, but I don't know 
off the top of my head which ones are those. But I would say std.meta is 
composed only of the former variety.

-Steve


More information about the Digitalmars-d mailing list