DIP54 : revamp of Phobos tuple types

Dicebot public at dicebot.lv
Sun Dec 29 20:03:30 PST 2013


On Monday, 30 December 2013 at 03:44:49 UTC, Andrei Alexandrescu 
wrote:
> I don't understand the question. I think there's no particular 
> relation between TemplateArgument{List,Pack}!(int, double) and 
> TemplateArgument{List,Pack}!(1, 2.0). One is a list of two 
> types and the other is a list of two values, and yah, if you 
> map typeof over the arguments in the latter it so happens you 
> get the types in the first.

See example in that post. Right now you can apply typeof to 
template argument list despite it not being a first class type 
and get list of types of its elements. It also only place in 
language where it allows to apply typeof on type:

is(typeof(TypeTuple!(42, int)) == TypeTuple!(int, int))

It gets worse when you consider so called expression lists:

TypeTuple!(int, double) vals;

This looks like instance of type list but it is in fact works 
(afaik) effectively as:

int _tmp1;
int _tmp2;

alias vals = TypeTuple!(_tmp1, _tmp2);

It is yet another special case that makes template argument list 
act as first class type despite not being one.

As you may have notice confusion is so high that Timon did not 
even believe me remembering your quote about no particular 
relation between those two :)

> One more word about providing TemplateArgument{List,Pack} vs. 
> only one of them. Our users fall into categories such as:
>
> 0. Language lawyers who've studied the fine distinctions and 
> are able to use either abstraction and define what they need if 
> missing.
>
> 1. Experts who have an understanding of what they need and 
> expect, and may or may not be surprised by whichever behavior 
> we choose.
>
> 2. Users who have only a vague idea what the power is, and 
> would have a difficult time using self-expansion when not 
> needed or vice versa.
>
> 3. Users who don't know the first thing about the entire notion 
> of grouping template arguments together.
>
> I think we'd harm one or more categories of these users if we 
> choose for them. We can't win. Conversely, we'd inform and 
> please them all if we attacked the matter head on with a 
> combination of TemplateArgument{List,Pack} and their afferent 
> documentation.

If it is you judgement, let it be so. I prefer to start working 
on implementation whatever it is as opposed to endless 
discussion. What is your opinion about defining general guideline 
to use packs over nested templates for multi-list algorithms 
(another disagreement between me and Jakob)?


More information about the Digitalmars-d mailing list