core.traits?

Steven Schveighoffer schveiguy at gmail.com
Mon Jan 7 21:54:15 UTC 2019


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), allSatisfy, anySatisfy, 
Filter, staticMap. We might as well just move the whole thing there.

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

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.

-Steve


More information about the Digitalmars-d mailing list