introduce "toTypeTuple"

[monarchdodra]

As suggested by @klickverbot in #1440, this pull supersedes staticIota by introducing a function that can transform any range a type tuple, including... iota.

In terms of performance, I guess it runs pretty fast. Compared to my hand written staticIota, toTypeTuple!iota, for a non release build, they both take the same ammount of time for iota(0, 1000), which is more than enough (IMO). That said, for larger sizes (eg 5000), toTypeTuple's performance does deteriorate. But at this point, the sizes are crazy huge in terms of static size...

In a release build, they both take longer, but are still comparable (however, they do a wall which ices the compiler after a certain size.)

I did not add constraints, because I was unsure if it was OK to import std.range in std.typetuple, as it imports very very little.

Pinging @denis-sh who might be interested.

All feedback welcome.

[denis-sh]

Again: expression tuple, not type tuple.

[jmdavis]

Again: expression tuple, not type tuple.

The result is a TypeTuple, so it makes sense that it would be called toTypeTuple. And while some TypeTuples could be called expression tuples based on what they hold, we have no ExpressionTuple, and it will just increase confusion to use that instead of TypeTuple. Regardless of what a TypeTuple contains, its name is TypeTuple, so toTypeTuple is correct.

[denis-sh]

The names in Phobos are confusing and all my attempts to change the situation failed. So, please just remember this:

1. generic tuple - any tuple,
2. expression tuple and type tuple - subsets of the first one. See isExpressionTuple and isTypeTuple.

Stuff returning

1. type tuple must start from upper letter as it will return a type;
2. expression tuple must start from lower letter as it will never return a type;
3. generic tuple must start from upper letter as it may return a type.

[denis-sh]

@jmdavis, looks like you are confused too (the explonation was originally for @monarchdodra).

[denis-sh]

A bit of history:
Tuples are clearly described in dlang.org's Tuples article. But as name Tuple is already in use by std.typecons.Tuple we have to use generic tuple term.

[jmdavis]

The result of toTypeTuple is a TypeTuple. I agree that the name TypeTuple isn't all that great, but at this point, we're stuck with it, because it would break too much code to change it, and I see zero value in trying to confusion things by throwing in the terms "type tuple," "expression tuple," and "generic tuple" on top of things. IMHO, we should just use the term TypeTuple and be done with it.

[denis-sh]

Are you talking about the developers? Because the users will read dlang.org's Tuples article and will see the terms I'm talking about.

[bearophile]

I hope this will become useless as soon we have a "static foreach":
http://d.puremagic.com/issues/show_bug.cgi?id=4085

See also kind of the opposite:
http://d.puremagic.com/issues/show_bug.cgi?id=9871

[jmdavis]

The fact that that article has

template Tuple(E...)
{
    alias E Tuple;
}

is horrendous. Tuple is std.typecons.Tuple, and the template that we have is TypeTuple. Heck calling any of the "tuples" in that article is bad given that they aren't really tuples, since they're always flat. The whole "tuple" situation is a mess. But what we have and what we're stuck with is TypeTuple, so I'm all for just sticking with that and not jumping into the whole confusion of "expression tuple" vs "type tuple."

[John-Colvin]

very nice :)

It's a pity about the tuple naming, but as Jonathan says, we're stuck with it.

Any reason not to merge this ASAP? (The auto-tester failures are network problems and some strange makefile thing that only happened once :/ it appears to have passed every test at least once)

[denis-sh]

@John-Colvin, are we continuing a bad comedy? I see no answer, who is stuck with TypeTuple name for generic tuples. I suppose only [some] Phobos developers do. The language (site and standard library) is stuck with confusing newcomers.

Unless you give me a mark "you are to stupid to be here, dear Denis", I will continue this topic because I was such newcomer. And I was unpleasantly surprised by the amount of time I had to waste just to understand the terminology (i.e. current confusing situation with tuples). Then I suggested to fix the situation and made a pull. And I was unpleasantly surprised again when it with was rejected and no other solution was suggested. Now I'm surprised the third time by "sombody is stuck with TypeTuple" words.

[John-Colvin]

Hmm. Perhaps you've got a point. See here for my take on it: http://forum.dlang.org/post/jagyupxiicevxrpnqewq@forum.dlang.org

[MartinNowak]

Is std.typecons the right place?
Can we find a compromise for the name?

[JakobOvrum]

Is std.typecons the right place?

It's in std.typetuple.

Can we find a compromise for the name?

I really wish Andrei and/or Walter would follow through with the renaming of type tuples. It has a really damaging effect for learners of the language.

[andralex]

Dicebot is working on a revamp of typetuple.

[JakobOvrum]

Dicebot is working on a revamp of typetuple.

I'm pretty sure that's orthogonal to the existing concept of type tuples, which are the ones we really need to rename.

[andralex]

I think that's exactly what he's working on. In particular his upcoming DIP will rename TypeTuple to TemplateArgumentList.

[JakobOvrum]

I don't think the renaming needs to wait for an implementation of non-expanding type tuples, which I thought was the bulk of his proposal. Pinging @Dicebot.

If "template argument list" and "TemplateArgumentList" are the officially sanctioned new names, we should go ahead with the rename ASAP (renaming of symbols, deprecations, updating dlang.org). I am worried about that particular name though - it doesn't seem to accommodate the equivalents of "expression tuple" and "type tuple", which is an important distinction.

[mihails-strasuns]

@JakobOvrum It does not need to wait but separating those makes deprecation / transition process ~twice longer and complicated. I have been busy since we came to some agreement in a mail conversation with @andralex but DIP to destroy will be out by Sunday.

I am worried about that particular name though - it doesn't seem to accommodate the equivalents of "expression tuple" and "type tuple", which is an important distinction

It is intentional as there is no strict distinction for it in language itself despite common confusion. Those are more use-case concepts than language / library concepts.

[JakobOvrum]

It is intentional as there is no strict distinction for it in language itself despite common confusion. Those are more use-case concepts than language / library concepts.

No, it is an important language concept, as type tuples can be used to declare expression tuples. That is the distinction.

[JakobOvrum]

It does not need to wait but separating those makes deprecation / transition process ~twice longer and complicated

I don't see how that could be the case. AFAICS, non-expanding tuples in the library are completely irrelvant to the current type tuples in the language.

[mihails-strasuns]

@JakobOvrum Rationalization is part of DIP. To put it shortly - we can't afford confusion of having both expanding and non-expanding library types. Former can be trivially got from latter via .expand but not the other way around. So deprecation of existing TypeTuple semantics needs to be made in favor of non-expanding one. It is a breaking change that needs proper transition process. Renaming is another breaking change that also needs same transition process. Doing those in one go (they target same symbol) saves a lot of time / maintenance efforts.

[monarchdodra]

For what it's worth, I have no problems waiting for the DIP. I have no real position on the matter, so I can just rename this to anything you'd want me to.

[JakobOvrum]

It sounds like I'll strongly dislike the proposal, but I guess I'll wait for the details to be posted.

[monarchdodra]

Closing until we decide where to go with TTs.

[monarchdodra]

Forgot to click "Close" ;)

[mihails-strasuns]

Link to DIP discussion thread for book-keeping - http://forum.dlang.org/post/ggxgongvmrdfajtbphis@forum.dlang.org
I am working on implementation.

[HK47196]

Is there any chance this can be reopened now? #3265 #3264

[jcrapuchettes]

Can this be updated and reopened?

[monarchdodra]

Yes. Could you update me on what needs to be done though? I've been out of the loop on recent events.

[rcorre]

This would be a great solution for the lack of a properly exposed staticIota.
I'd imagine the 'updates' revolve around the renaming of std.typetuple to std.meta and TypeTuple to AliasSeq.

[rcorre]

scratch that, I guess it was already implemented as AliasSeqOf.