www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - s/type tuple/template pack/g please

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
There's an inordinate amount of confusion around what we currently call 
"type tuple" (embodied in std's TypeTuple). I've been furious 
immediately as I got word that Walter called it that way, and it hasn't 
failed to make everybody else feel the same over the years.

So: shall we use "template pack" going forward exclusively whenever we 
refer to that stuff? That way we can unambiguously use "tuple" for 
"value tuples, i.e. like mini-structs that group values together".

Destroy. I mean criticize.



Andrei
Aug 21 2013
next sibling parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
 So: shall we use "template pack" going forward exclusively 
 whenever we refer to that stuff? That way we can unambiguously 
 use "tuple" for "value tuples, i.e. like mini-structs that 
 group values together".

 Destroy. I mean criticize.
Yes, let's make sure to avoid any undue confusion.
Aug 21 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
 There's an inordinate amount of confusion around what we 
 currently call "type tuple" (embodied in std's TypeTuple). I've 
 been furious immediately as I got word that Walter called it 
 that way, and it hasn't failed to make everybody else feel the 
 same over the years.

 So: shall we use "template pack" going forward exclusively 
 whenever we refer to that stuff? That way we can unambiguously 
 use "tuple" for "value tuples, i.e. like mini-structs that 
 group values together".

 Destroy. I mean criticize.

 Andrei
http://forum.dlang.org/post/lrycaqlrtwylhbxfifyz forum.dlang.org ;)
 Define two distinct built-in "tuples":

     - Template argument sequence: may contain anything that is 
 legal template
         argument.
     - Value tuple or simply "tuple": may contain any values, 
 including run-time
     values. Value storage location is not defined.
"pack" is dangerous word to chose until packing/unpacking semantics are set in stone.
Aug 21 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
 There's an inordinate amount of confusion around what we 
 currently call "type tuple" (embodied in std's TypeTuple). I've 
 been furious immediately as I got word that Walter called it 
 that way, and it hasn't failed to make everybody else feel the 
 same over the years.

 So: shall we use "template pack" going forward exclusively 
 whenever we refer to that stuff? That way we can unambiguously 
 use "tuple" for "value tuples, i.e. like mini-structs that 
 group values together".
"template pack" isn't really clearer to me than "type tuple", IMO: Both only mean what we want them to mean (Kind of like RAII). If we want to be clearer/more accurate, then something along the lines of "variadic pack" or "variadic list" would be more descriptive.
Aug 21 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/21/13 11:10 AM, monarch_dodra wrote:
 On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu wrote:
 There's an inordinate amount of confusion around what we currently
 call "type tuple" (embodied in std's TypeTuple). I've been furious
 immediately as I got word that Walter called it that way, and it
 hasn't failed to make everybody else feel the same over the years.

 So: shall we use "template pack" going forward exclusively whenever we
 refer to that stuff? That way we can unambiguously use "tuple" for
 "value tuples, i.e. like mini-structs that group values together".
"template pack" isn't really clearer to me than "type tuple", IMO: Both only mean what we want them to mean (Kind of like RAII). If we want to be clearer/more accurate, then something along the lines of "variadic pack" or "variadic list" would be more descriptive.
I agree. Let's have an epic debate once and for all for the right name, and then use it consistently. This is one of those instances in which it becomes painfully obvious that names do matter. Andrei
Aug 21 2013
prev sibling next sibling parent reply "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
 So: shall we use "template pack" going forward exclusively 
 whenever we refer to that stuff?
Yes, we need do do something about this, and the sooner, the better. However, I am not particularly happy with the name "template pack", for two reasons: a) To me, the name suggests that a "template pack" would consist of templates. In this regard, I'd prefer "parameter pack", which also seems to catch on in the C++ community for the (almost, but not entirely dis-)similar C++11 construct. b) "Pack" is somewhat unintuitive for an entity that is automatically unpacked in many contexts. For example, std.typetuple (internally) defines a "Pack" template that is used precisely for avoiding that intrinsic property of argument lists. Personally, I like using "Seq" as the name for the constructor template, as do a few other of the GitHub/NG regulars, so maybe "(parameter/variadic/…) sequence" would be an alternative worth discussing? In any case, I'd be fine with almost any color for the bike shed, as long as it is not the current one. ;) David
Aug 21 2013
next sibling parent reply "Atash" <nope nope.nope> writes:
On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger 
wrote:
  a) To me, the name suggests that a "template pack" would 
 consist of templates. In this regard, I'd prefer "parameter 
 pack", which also seems to catch on in the C++ community for 
 the (almost, but not entirely dis-)similar C++11 construct.
My backpack isn't full of backs, though... In all seriousness (assuming I'm capable of being serious), I don't see wording 'template pack' being problematic, assuming that there's really no other way to use them but through templates (which AFAIK they can't). The word 'parameter' overlaps somewhat in my head with the 'Params' DDoc command, and really just seems to be uber general with respect to the word parameterization. If you look at this: http://en.cppreference.com/w/cpp/language/parameter_pack ... there's a qualification of the concept 'parameter pack' on the very first line: '*template* parameter pack'. This to me is indicative that someone realized that the reader, having little other experience with this feature in C++ (else why would they be reading the article?) might be initially confused if the first phrase they encountered wasn't qualified by the word 'template', because that's what the feature was meant to be used in the context of.
 [...]
 
 Personally, I like using "Seq" as the name for the constructor 
 template, as do a few other of the GitHub/NG regulars, so maybe 
 "(parameter/variadic/…) sequence" would be an alternative worth 
 discussing?
I'm just... reaaaalllyyyy uncomfortable with anything of the form [name-used-in-other-feature-of-language-that-existed-back-in-C] [collection-of-whatever-the-previous-word-was].
 In any case, I'd be fine with almost any color for the bike 
 shed, as long as it is not the current one. ;)

 David
Blue!
Aug 21 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/21/2013 11:40 AM, Atash wrote:

 I don't see wording 'template pack' being problematic, assuming that 
there's
 really no other way to use them but through templates (which AFAIK they
 can't).
TypeTuple can represent function parameter lists and array literal lists as well: import std.typetuple; void func(int, int) {} struct S(int a, int b) {} void main() { alias tt = TypeTuple!(1, 2); func(tt); auto o = S!tt(); auto arr = [ tt ]; } Ali
Aug 21 2013
parent "Atash" <nope nope.nope> writes:
On Wednesday, 21 August 2013 at 18:50:30 UTC, Ali Çehreli wrote:
 On 08/21/2013 11:40 AM, Atash wrote:

 I don't see wording 'template pack' being problematic,
assuming that there's
 really no other way to use them but through templates (which
AFAIK they
 can't).
TypeTuple can represent function parameter lists and array literal lists as well:
Under the assumption that the following was meant to be a counterpoint...
 import std.typetuple;

 void func(int, int)
 {}

 struct S(int a, int b)
 {}

 void main()
 {
     alias tt = TypeTuple!(1, 2);
^ I'm not seeing the case given that TypeTuple is a template. == What are we *actually* talking about? I feel like this wasn't well defined, because now I'm feeling mildly confused with where the discussion has gone. template Stuff(A...) { <stuff> } // a sequence/tuple of template parameters alias TypeTuple!(<stuff>) B; // std.TypeTuple TypeTuple!(<stuff>) C; // value tuple I'm inclined to say that the debate is currently about A, but just to make sure... are we talking about A, B, C, or something else entirely? == Annnddd more general stuff Under the assumption that we are talking about A in the section above... IMO, it's almost inevitable that whatever noun you guys decide on is going to be preceded by the word 'template' in conversation and in written communication if it isn't there already. While that sort of casual wording may be easily relegated to a synonym, it's still worth thinking about, methinks.
Aug 22 2013
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger 
wrote:
 Personally, I like using "Seq" as the name for the constructor 
 template, as do a few other of the GitHub/NG regulars, so maybe 
 "(parameter/variadic/…) sequence" would be an alternative worth 
 discussing?
"Seq" is nice too because it has no baggage that comes with terms like "type", "tuple", or "template". It's its own thing which hasn't been used to mean anything but what people are proposing (at least in the context of D). I think I actually like "Seq" better than "parameter/variadic sequence" for this reason. Neologism is a perfectly valid option (isn't that right, trie?).
Aug 21 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/21/13 12:01 PM, Brad Anderson wrote:
 On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger wrote:
 Personally, I like using "Seq" as the name for the constructor
 template, as do a few other of the GitHub/NG regulars, so maybe
 "(parameter/variadic/…) sequence" would be an alternative worth
 discussing?
"Seq" is nice too because it has no baggage that comes with terms like "type", "tuple", or "template". It's its own thing which hasn't been used to mean anything but what people are proposing (at least in the context of D). I think I actually like "Seq" better than "parameter/variadic sequence" for this reason. Neologism is a perfectly valid option (isn't that right, trie?).
"Seq" has the problem that it's not an actual word or phrase and as such is difficult to talk about. Andrei
Aug 21 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 21 August 2013 at 19:19:35 UTC, Andrei Alexandrescu 
wrote:
 On 8/21/13 12:01 PM, Brad Anderson wrote:
 On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger 
 wrote:
 Personally, I like using "Seq" as the name for the constructor
 template, as do a few other of the GitHub/NG regulars, so 
 maybe
 "(parameter/variadic/…) sequence" would be an alternative 
 worth
 discussing?
"Seq" is nice too because it has no baggage that comes with terms like "type", "tuple", or "template". It's its own thing which hasn't been used to mean anything but what people are proposing (at least in the context of D). I think I actually like "Seq" better than "parameter/variadic sequence" for this reason. Neologism is a perfectly valid option (isn't that right, trie?).
"Seq" has the problem that it's not an actual word or phrase and as such is difficult to talk about. Andrei
Seeing as basically all the "talking" is actually typing, I don't really see how this is a problem.
Aug 21 2013
prev sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 21 August 2013 at 19:19:35 UTC, Andrei Alexandrescu 
wrote:
 On 8/21/13 12:01 PM, Brad Anderson wrote:
 On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger 
 wrote:
 Personally, I like using "Seq" as the name for the constructor
 template, as do a few other of the GitHub/NG regulars, so 
 maybe
 "(parameter/variadic/…) sequence" would be an alternative 
 worth
 discussing?
"Seq" is nice too because it has no baggage that comes with terms like "type", "tuple", or "template". It's its own thing which hasn't been used to mean anything but what people are proposing (at least in the context of D). I think I actually like "Seq" better than "parameter/variadic sequence" for this reason. Neologism is a perfectly valid option (isn't that right, trie?).
"Seq" has the problem that it's not an actual word or phrase and as such is difficult to talk about. Andrei
Nobody seems to know how to say "trie" either but it's successful enough (look at this show of hands: http://www.youtube.com/watch?v=RlVpPstLPEc&feature=youtu.be&t=50m46s ). I would just pronounce it like abbreviated "sequence" so IPA: sikw. Anyway, I think an neologism is something to consider even if it isn't Seq.
Aug 21 2013
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
 There's an inordinate amount of confusion around what we 
 currently call "type tuple" (embodied in std's TypeTuple). I've 
 been furious immediately as I got word that Walter called it 
 that way, and it hasn't failed to make everybody else feel the 
 same over the years.

 So: shall we use "template pack" going forward exclusively 
 whenever we refer to that stuff? That way we can unambiguously 
 use "tuple" for "value tuples, i.e. like mini-structs that 
 group values together".

 Destroy. I mean criticize.



 Andrei
There are a lot of good names for it: Template Pack, Type Sequence, Template Argument List, Type List, etc. I think I like Type Sequence the best but any will do. All that really matters is getting Tuple out of the name to clear up the confusion. http://dlang.org/tuple.html is so confusing to anyone who has used tuples in other languages. It doesn't even mention typecons' Tuples which is what anyone who would click on that link would be looking for. It also might be a good time to clear some things up about them in the spec (and possibly implementation). Timon's link to http://wiki.dlang.org/The_D_Programming_Language/Seq shows some areas where they are inconsistent or confusing.
Aug 21 2013
next sibling parent "Dicebot" <public dicebot.lv> writes:
On Wednesday, 21 August 2013 at 18:21:39 UTC, Brad Anderson wrote:
 There are a lot of good names for it: Template Pack, Type 
 Sequence, Template Argument List, Type List, etc. I think I 
 like Type Sequence the best but any will do.  All that really 
 matters is getting Tuple out of the name to clear up the 
 confusion.
Please, nothing with "Type" in its name. How can you call a "type sequence" thing that does not contain types? Same confusion.
Aug 21 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/21/13 11:21 AM, Brad Anderson wrote:
 On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu wrote:
 There's an inordinate amount of confusion around what we currently
 call "type tuple" (embodied in std's TypeTuple). I've been furious
 immediately as I got word that Walter called it that way, and it
 hasn't failed to make everybody else feel the same over the years.

 So: shall we use "template pack" going forward exclusively whenever we
 refer to that stuff? That way we can unambiguously use "tuple" for
 "value tuples, i.e. like mini-structs that group values together".

 Destroy. I mean criticize.



 Andrei
There are a lot of good names for it: Template Pack, Type Sequence, Template Argument List, Type List, etc. I think I like Type Sequence the best but any will do. All that really matters is getting Tuple out of the name to clear up the confusion.
We much more need to get "type" out of the name. Those aren't types. Andrei
Aug 21 2013
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu 
wrote:
 We much more need to get "type" out of the name. Those aren't 
 types.
I think this is part of the problem. Nobody can agree on what they should be called because it's so hard to classify them. They're not types, they're not values, they're this weird in-between thing that can be either one, or the other, or both. Therefore anything containing Type or Value in the name will not describe exactly what this thing is. Neither will Symbol, nor Expression, as it can contain both of those again, but not exclusively. We may as well call it by some name that is completely unrelated to what it can contain, as it can contain pretty much *everything*. How about KitchenSinkquence?
Aug 21 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/21/13 11:36 AM, Meta wrote:
 On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu wrote:
 We much more need to get "type" out of the name. Those aren't types.
I think this is part of the problem. Nobody can agree on what they should be called because it's so hard to classify them.
They're not hard to classify. They are anything that can be passed to a template. Andrei
Aug 21 2013
parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 21 August 2013 at 18:44:14 UTC, Andrei Alexandrescu 
wrote:
 I think this is part of the problem. Nobody can agree on what 
 they
 should be called because it's so hard to classify them.
They're not hard to classify. They are anything that can be passed to a template.
Maybe I'm splitting hairs, but that's what goes into them. Not what they *are*. So what goes into a template? Expressions, Types, Symbols. I can't think of something off the top of my head that covers all three of these. Expressing that it's a container is easy, but expressing what that container can contain is not, unless you want to call it ListOfStuffThatCanBePassedToATemplate.
Aug 21 2013
prev sibling next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 21.08.2013 20:36, schrieb Meta:
 On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu
 wrote:
 We much more need to get "type" out of the name. Those aren't
 types.
I think this is part of the problem. Nobody can agree on what they should be called because it's so hard to classify them. They're not types, they're not values, they're this weird in-between thing that can be either one, or the other, or both. Therefore anything containing Type or Value in the name will not describe exactly what this thing is. Neither will Symbol, nor Expression, as it can contain both of those again, but not exclusively. We may as well call it by some name that is completely unrelated to what it can contain, as it can contain pretty much *everything*. How about KitchenSinkquence?
what about "alias list", "alias sequence" - seems to be more in that directory - but not 100%
Aug 21 2013
prev sibling parent reply captaindet <2krnk gmx.net> writes:
On 2013-08-21 13:36, Meta wrote:
 On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu
 wrote:
 We much more need to get "type" out of the name. Those aren't
 types.
I think this is part of the problem. Nobody can agree on what they should be called because it's so hard to classify them. They're not types, they're not values, they're this weird in-between thing that can be either one, or the other, or both. Therefore anything containing Type or Value in the name will not describe exactly what this thing is. Neither will Symbol, nor Expression, as it can contain both of those again, but not exclusively. We may as well call it by some name that is completely unrelated to what it can contain, as it can contain pretty much *everything*. How about KitchenSinkquence?
abstract tuples they are. (we have to alias them to maintain their full function) i don't mind them being called ...tuples, to me it looks and feels enough like a tuple to be called this way. (Type... is very confusing though). concerning the other typecons.Tuple: i think of this being more an issue of insufficient/bad/confusing documentation. /det
Aug 21 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-21 21:48, captaindet wrote:

 abstract tuples they are.

 (we have to alias them to maintain their full function)

 i don't mind them being called ...tuples, to me it looks and feels
 enough like a tuple to be called this way. (Type... is very confusing
 though).

 concerning the other typecons.Tuple: i think of this being more an issue
 of insufficient/bad/confusing documentation.
We could call the built-in ones for "tuple" and typecons.Tuple for anonymous structs. -- /Jacob Carlborg
Aug 22 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, August 22, 2013 09:21:05 Jacob Carlborg wrote:
 On 2013-08-21 21:48, captaindet wrote:
 abstract tuples they are.
 
 (we have to alias them to maintain their full function)
 
 i don't mind them being called ...tuples, to me it looks and feels
 enough like a tuple to be called this way. (Type... is very confusing
 though).
 
 concerning the other typecons.Tuple: i think of this being more an issue
 of insufficient/bad/confusing documentation.
We could call the built-in ones for "tuple" and typecons.Tuple for anonymous structs.
Considering that std.typecons.Tuple actually acts like a full-on tuple (it actually nests) and the built-in "tuple" doesn't, that would be an odd choice IMHO. - Jonathan M Davis
Aug 22 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-08-22 09:29, Jonathan M Davis wrote:

 Considering that std.typecons.Tuple actually acts like a full-on tuple (it
 actually nests) and the built-in "tuple" doesn't, that would be an odd choice
 IMHO.
I don't know the exact definition of "tuple" but what have nesting to do with it? You can add names to the values using std.typecons.Tuple alias Tuple!(int, "index", string, "value") Entry; Entry e; e.index = 4; e.value = "Hello"; assert(e[1] == "Hello"); assert(e[0] == 4); The above is basically exactly like an anonymous struct. -- /Jacob Carlborg
Aug 22 2013
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu 
wrote:
 On 8/21/13 11:21 AM, Brad Anderson wrote:
 On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei 
 Alexandrescu wrote:
 There's an inordinate amount of confusion around what we 
 currently
 call "type tuple" (embodied in std's TypeTuple). I've been 
 furious
 immediately as I got word that Walter called it that way, and 
 it
 hasn't failed to make everybody else feel the same over the 
 years.

 So: shall we use "template pack" going forward exclusively 
 whenever we
 refer to that stuff? That way we can unambiguously use 
 "tuple" for
 "value tuples, i.e. like mini-structs that group values 
 together".

 Destroy. I mean criticize.



 Andrei
There are a lot of good names for it: Template Pack, Type Sequence, Template Argument List, Type List, etc. I think I like Type Sequence the best but any will do. All that really matters is getting Tuple out of the name to clear up the confusion.
We much more need to get "type" out of the name. Those aren't types. Andrei
Alright. I always found the Tuple part more confusing but I guess I'm in the minority since three people all jumped on the "type" portion of my comment at once.
Aug 21 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/21/13 11:44 AM, Brad Anderson wrote:
 On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu wrote:
 On 8/21/13 11:21 AM, Brad Anderson wrote:
 On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu wrote:
 There's an inordinate amount of confusion around what we currently
 call "type tuple" (embodied in std's TypeTuple). I've been furious
 immediately as I got word that Walter called it that way, and it
 hasn't failed to make everybody else feel the same over the years.

 So: shall we use "template pack" going forward exclusively whenever we
 refer to that stuff? That way we can unambiguously use "tuple" for
 "value tuples, i.e. like mini-structs that group values together".

 Destroy. I mean criticize.



 Andrei
There are a lot of good names for it: Template Pack, Type Sequence, Template Argument List, Type List, etc. I think I like Type Sequence the best but any will do. All that really matters is getting Tuple out of the name to clear up the confusion.
We much more need to get "type" out of the name. Those aren't types. Andrei
Alright. I always found the Tuple part more confusing but I guess I'm in the minority since three people all jumped on the "type" portion of my comment at once.
"Tuple" needs to go as well, although that entity does look like a tuple in some respects. Andrei
Aug 21 2013
parent "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 21 August 2013 at 18:45:49 UTC, Andrei Alexandrescu 
wrote:
 On 8/21/13 11:44 AM, Brad Anderson wrote:
 On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei 
 Alexandrescu wrote:
 On 8/21/13 11:21 AM, Brad Anderson wrote:
 On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei 
 Alexandrescu wrote:
 There's an inordinate amount of confusion around what we 
 currently
 call "type tuple" (embodied in std's TypeTuple). I've been 
 furious
 immediately as I got word that Walter called it that way, 
 and it
 hasn't failed to make everybody else feel the same over the 
 years.

 So: shall we use "template pack" going forward exclusively 
 whenever we
 refer to that stuff? That way we can unambiguously use 
 "tuple" for
 "value tuples, i.e. like mini-structs that group values 
 together".

 Destroy. I mean criticize.



 Andrei
There are a lot of good names for it: Template Pack, Type Sequence, Template Argument List, Type List, etc. I think I like Type Sequence the best but any will do. All that really matters is getting Tuple out of the name to clear up the confusion.
We much more need to get "type" out of the name. Those aren't types. Andrei
Alright. I always found the Tuple part more confusing but I guess I'm in the minority since three people all jumped on the "type" portion of my comment at once.
"Tuple" needs to go as well, although that entity does look like a tuple in some respects. Andrei
Yeah, the name "tuple" isn't actually all that inaccurate. The problem is more that it places too much load on the word for two very distinct things.
Aug 21 2013
prev sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Wednesday, 21 August 2013 at 18:21:39 UTC, Brad Anderson wrote:
 I think I like Type Sequence the best but any will do.
I think we should make sure to drop "type" from the name – to me, it seems like one of the major points of confusion with TypeTuple is that they do not only consist of types. David
Aug 21 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
 There's an inordinate amount of confusion around what we 
 currently call "type tuple" (embodied in std's TypeTuple). I've 
 been furious immediately as I got word that Walter called it 
 that way, and it hasn't failed to make everybody else feel the 
 same over the years.

 So: shall we use "template pack" going forward exclusively 
 whenever we refer to that stuff? That way we can unambiguously 
 use "tuple" for "value tuples, i.e. like mini-structs that 
 group values together".

 Destroy. I mean criticize.



 Andrei
I'd say go with Seq as has been suggested by some people. It can't be confused with types, tuples or (un)packing. It could be extended to ParameterSequence or ParameterSeq or ParamSeq or whatever. Either way, it doesn't appear to have any glaring problems.
Aug 21 2013
prev sibling next sibling parent reply "Regan Heath" <regan netmail.co.nz> writes:
On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 There's an inordinate amount of confusion around what we currently call  
 "type tuple" (embodied in std's TypeTuple). I've been furious  
 immediately as I got word that Walter called it that way, and it hasn't  
 failed to make everybody else feel the same over the years.

 So: shall we use "template pack" going forward exclusively whenever we  
 refer to that stuff? That way we can unambiguously use "tuple" for  
 "value tuples, i.e. like mini-structs that group values together".

 Destroy. I mean criticize.
After reading the thread I think it might help to try to define the important characteristics of them, and from that select the key Using this as a reference to my understanding: http://wiki.dlang.org/The_D_Programming_Language/Seq In particular the section: "Q: What's the deal with "auto-expansion"?" I think .. "type tuples" are: - Compile time - A kind of (list, set, group, or collection) of (parameters/arguments, initialisers, parent classes) - Flat i.e. "auto expanded" where used, not nested. - An alias for the elements it contains - A <thing> in which the ordering is important I am leaning toward the fact that they are an "alias" being a key property, that and the fact that they are a "list" or "set" of things. "Sequence" may be even better than list as it imples more heavily that the ordering is important. So, I am personally leaning toward dennis's suggestion of "Alias Sequence". But, I do worry a little about overloading the term "alias". However.. TypeTuple is defined using "alias" so maybe they are the "same thing" after all. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Aug 22 2013
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 22.08.2013 12:05, schrieb Regan Heath:
 On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 There's an inordinate amount of confusion around what we currently call
 "type tuple" (embodied in std's TypeTuple). I've been furious
 immediately as I got word that Walter called it that way, and it hasn't
 failed to make everybody else feel the same over the years.

 So: shall we use "template pack" going forward exclusively whenever we
 refer to that stuff? That way we can unambiguously use "tuple" for
 "value tuples, i.e. like mini-structs that group values together".

 Destroy. I mean criticize.
After reading the thread I think it might help to try to define the important characteristics of them, and from that select the key Using this as a reference to my understanding: http://wiki.dlang.org/The_D_Programming_Language/Seq In particular the section: "Q: What's the deal with "auto-expansion"?" I think .. "type tuples" are: - Compile time - A kind of (list, set, group, or collection) of (parameters/arguments, initialisers, parent classes) - Flat i.e. "auto expanded" where used, not nested. - An alias for the elements it contains - A <thing> in which the ordering is important I am leaning toward the fact that they are an "alias" being a key property, that and the fact that they are a "list" or "set" of things. "Sequence" may be even better than list as it imples more heavily that the ordering is important. So, I am personally leaning toward dennis's suggestion of "Alias Sequence". But, I do worry a little about overloading the term "alias". However.. TypeTuple is defined using "alias" so maybe they are the "same thing" after all. R
~but~ an "alias sequence" item is different to an alias an alias can't contain untyped values: alias x = 5; alias y = "hallo"; an alias is an real accessible symbol - not just an position in a sequence or am i wrong here?
Aug 22 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 22 August 2013 at 10:32:06 UTC, dennis luehring 
wrote:
 ~but~ an "alias sequence" item is different to an alias

 an alias can't contain untyped values:

 alias x = 5;
 alias y = "hallo";

 an alias is an real accessible symbol - not just an position in 
 a sequence

 or am i wrong here?
Function literal are passed around via alias all over the place.
Aug 22 2013
prev sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 22 Aug 2013 11:32:06 +0100, dennis luehring <dl.soluz gmx.net>  
wrote:

 Am 22.08.2013 12:05, schrieb Regan Heath:
 On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 There's an inordinate amount of confusion around what we currently call
 "type tuple" (embodied in std's TypeTuple). I've been furious
 immediately as I got word that Walter called it that way, and it hasn't
 failed to make everybody else feel the same over the years.

 So: shall we use "template pack" going forward exclusively whenever we
 refer to that stuff? That way we can unambiguously use "tuple" for
 "value tuples, i.e. like mini-structs that group values together".

 Destroy. I mean criticize.
After reading the thread I think it might help to try to define the important characteristics of them, and from that select the key Using this as a reference to my understanding: http://wiki.dlang.org/The_D_Programming_Language/Seq In particular the section: "Q: What's the deal with "auto-expansion"?" I think .. "type tuples" are: - Compile time - A kind of (list, set, group, or collection) of (parameters/arguments, initialisers, parent classes) - Flat i.e. "auto expanded" where used, not nested. - An alias for the elements it contains - A <thing> in which the ordering is important I am leaning toward the fact that they are an "alias" being a key property, that and the fact that they are a "list" or "set" of things. "Sequence" may be even better than list as it imples more heavily that the ordering is important. So, I am personally leaning toward dennis's suggestion of "Alias Sequence". But, I do worry a little about overloading the term "alias". However.. TypeTuple is defined using "alias" so maybe they are the "same thing" after all. R
an alias is an real accessible symbol - not just an position in a sequence or am i wrong here?
That's not quite what I was trying to say. I see it as the Alias Sequence being an alias for the entire sequence of symbols/expressions in the ordering in which they are given/defined. That said, to actually use them as aliases you need to name them, with an "alias" expression, e.g. // inspired by http://wiki.dlang.org/The_D_Programming_Language/Seq import std.stdio; template AliasSeqence(T...){ alias AliasSeqence = T; } alias one = AliasSeqence!(1); alias onetwo = AliasSeqence!(one,2); alias parented = AliasSeqence!(B,C); alias orphaned = AliasSeqence!(); // Parent list: interface C { } class B: orphaned { } // meaning: class B{ } class A: parented // meaning: class A: B,C{ } { this(int a, int b) { writefln("A.a = %d, A.b = %d", a, b); } } // Array literal element list: int[] digits = [0,onetwo,3]; // meaning: [0,1,2,3] void foo(int a, int b, int c) { writefln("foo(%d,%d,%d)", a, b, c); } void Foo(int a, int b, int c)() { writefln("Foo(%d,%d,%d)", a, b, c); } void main() { writefln("digits = %s", digits); // Function argument list (including struct constructor calls, excluding arguments to overloaded operators): foo(onetwo,3); // meaning: foo(1,2,3) // Template argument list (this is why you cannot have argument lists nested within argument lists). Foo!(0,onetwo)(); // meaning: Foo!(0,1,2) // Index argument list: int[] arr = new int[2]; arr[one] = 2; // meaning: arr[1] writefln("arr[one]=%d", arr[one]); // New argument list(s): A a = new A(onetwo); // meaning new A(1,2) } R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Aug 22 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
 There's an inordinate amount of confusion around what we 
 currently call "type tuple" (embodied in std's TypeTuple). I've 
 been furious immediately as I got word that Walter called it 
 that way, and it hasn't failed to make everybody else feel the 
 same over the years.

 So: shall we use "template pack" going forward exclusively 
 whenever we refer to that stuff? That way we can unambiguously 
 use "tuple" for "value tuples, i.e. like mini-structs that 
 group values together".

 Destroy. I mean criticize.
Many people started to use the sequence term. I think we should stick for that one. Pack is kind of misleading IMO, as they automagically unpack. So template argument sequence. If they happen to all be types/alias/values, types/alias/values sequence.
Aug 22 2013
prev sibling next sibling parent reply "Tommi" <tommitissari hotmail.com> writes:
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
 So: shall we use "template pack" going forward exclusively 
 whenever we refer to that stuff?
I think it should be called either a "compile-time list" or a "static list", because it's a list of things which can be referred to at compile-time. import std.typetuple; void main() { int n; alias T = TypeTuple!(int, 4, n); static assert(T[1] == 4); T[2]++; assert(n == 1); }
Aug 22 2013
parent reply "Tommi" <tommitissari hotmail.com> writes:
On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:
 I think it should be called either a "compile-time list" ...
And if we go with "compile-time list", then we can follow the example of std.regex.ctRegex and name the thing "ctList".
Aug 22 2013
next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 22 Aug 2013 12:55:55 +0100, Tommi <tommitissari hotmail.com> wrote:

 On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:
 I think it should be called either a "compile-time list" ...
And if we go with "compile-time list", then we can follow the example of std.regex.ctRegex and name the thing "ctList".
+1 I like this suggestion also. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Aug 22 2013
prev sibling parent reply Michel Fortin <michel.fortin michelf.ca> writes:
On 2013-08-22 11:55:55 +0000, "Tommi" <tommitissari hotmail.com> said:

 On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:
 I think it should be called either a "compile-time list" ...
And if we go with "compile-time list", then we can follow the example of std.regex.ctRegex and name the thing "ctList".
Will .tupleof become .ctlistof? -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Aug 22 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:
 On 2013-08-22 11:55:55 +0000, "Tommi" 
 <tommitissari hotmail.com> said:

 On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:
 I think it should be called either a "compile-time list" ...
And if we go with "compile-time list", then we can follow the example of std.regex.ctRegex and name the thing "ctList".
Will .tupleof become .ctlistof?
strictly speaking I think it would be an alias list, so perhaps .aliasList
Aug 22 2013
prev sibling next sibling parent "Tommi" <tommitissari hotmail.com> writes:
On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:
 On 2013-08-22 11:55:55 +0000, "Tommi" 
 <tommitissari hotmail.com> said:

 On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:
 I think it should be called either a "compile-time list" ...
And if we go with "compile-time list", then we can follow the example of std.regex.ctRegex and name the thing "ctList".
Will .tupleof become .ctlistof?
I think it could be .fieldsof
Aug 22 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:
 On 2013-08-22 11:55:55 +0000, "Tommi" 
 <tommitissari hotmail.com> said:

 On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:
 I think it should be called either a "compile-time list" ...
And if we go with "compile-time list", then we can follow the example of std.regex.ctRegex and name the thing "ctList".
Will .tupleof become .ctlistof?
This feature should be dropped and provided as library using compile time reflection.
Aug 22 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/22/2013 03:07 PM, deadalnix wrote:
 On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:
 On 2013-08-22 11:55:55 +0000, "Tommi" <tommitissari hotmail.com> said:

 On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:
 I think it should be called either a "compile-time list" ...
And if we go with "compile-time list", then we can follow the example of std.regex.ctRegex and name the thing "ctList".
Will .tupleof become .ctlistof?
This feature should be dropped and provided as library using compile time reflection.
How to bypass protection attributes?
Aug 22 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 22 August 2013 at 13:10:28 UTC, Timon Gehr wrote:
 On 08/22/2013 03:07 PM, deadalnix wrote:
 On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin 
 wrote:
 On 2013-08-22 11:55:55 +0000, "Tommi" 
 <tommitissari hotmail.com> said:

 On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:
 I think it should be called either a "compile-time list" ...
And if we go with "compile-time list", then we can follow the example of std.regex.ctRegex and name the thing "ctList".
Will .tupleof become .ctlistof?
This feature should be dropped and provided as library using compile time reflection.
How to bypass protection attributes?
compile time reflection should be able to do it. Discussion has been raised many time.
Aug 22 2013
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu 
wrote:
 There's an inordinate amount of confusion around what we 
 currently call "type tuple" (embodied in std's TypeTuple). I've 
 been furious immediately as I got word that Walter called it 
 that way, and it hasn't failed to make everybody else feel the 
 same over the years.

 So: shall we use "template pack" going forward exclusively 
 whenever we refer to that stuff? That way we can unambiguously 
 use "tuple" for "value tuples, i.e. like mini-structs that 
 group values together".
I'm fine with any name but would like to point out that it's probably essential that the new name allows for the distinction between what we currently call type tuples and expression/mixed tuples. The latter are not so important to distinguish, but type tuples have the privilege of being able to declare an expression tuple: TypeTuple!(int, string) myExpressionTuple; myExpressionTuple[0] = 42; myExpressionTuple[1] = "foo"; // etc If we don't have an easy way to refer to this distinction with the new naming, it may not be adequate enough for everyone to discard the old, confusing names, which could potentially seriously stall adoption, as it would be tempting to use the old terms in certain situations. We also have the naming of std.traits' `isTypeTuple` and `isExpressionTuple` to think about. On a different tangent; changes like this are probably easier to push through when they have a strong air of officialness. Thank you for starting the process with this thread. An idea would be to have Walter and/or yourself (Andrei) pick a short list of names you think make the most sense after the discussion has unfolded, then put them on a vote. If it ends in a tie, the two of you could exercise executive discretion in choosing the winner. The result could then be an official announcement that we could share in the community to further adoption.
 Destroy. I mean criticize.
Oh please, I think "destroy" reflects a healthy prevalence of openness to criticism in this community, let's not stop using it just because one or two newbies have announced some mild displeasure with it :P
Aug 22 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 22 August 2013 at 13:39:25 UTC, Jakob Ovrum wrote:
 I'm fine with any name but would like to point out that it's 
 probably essential that the new name allows for the distinction 
 between what we currently call type tuples and expression/mixed 
 tuples. The latter are not so important to distinguish, but 
 type tuples have the privilege of being able to declare an 
 expression tuple:

     TypeTuple!(int, string) myExpressionTuple;
     myExpressionTuple[0] = 42;
     myExpressionTuple[1] = "foo";
     // etc
One extra source of confusion is that "expression tuple" was often used for TypeTuple!(42, "foo") ones, not for runtime instances. Those two are very different in D. That is why I am saying one name is not enough and some classification is needed.
Aug 22 2013
next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote:
 One extra source of confusion is that "expression tuple" was 
 often used for TypeTuple!(42, "foo") ones, not for runtime 
 instances. Those two are very different in D. That is why I am 
 saying one name is not enough and some classification is needed.
They are one and the same.
Aug 22 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 22 August 2013 at 13:46:12 UTC, Jakob Ovrum wrote:
 On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote:
 One extra source of confusion is that "expression tuple" was 
 often used for TypeTuple!(42, "foo") ones, not for runtime 
 instances. Those two are very different in D. That is why I am 
 saying one name is not enough and some classification is 
 needed.
They are one and the same.
Almost, but not completely. They share implementation and much of observable behavior (and former can be used to initialize latter) but one is mutable run-time entity and other - compile-time (and thus, of course, constant). As they don't have proper representation in the type system, it makes them quite different.
Aug 22 2013
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Thursday, 22 August 2013 at 13:53:45 UTC, Dicebot wrote:
 Almost, but not completely. They share implementation and much 
 of observable behavior (and former can be used to initialize 
 latter) but one is mutable run-time entity and other - 
 compile-time (and thus, of course, constant). As they don't 
 have proper representation in the type system, it makes them 
 quite different.
I don't think it's correct or useful to label one as compile-time and the other as runtime. I think the mutability or immutability of the expression tuple is an obvious result of its lvalue-ish or rvalue-ish nature, respectively. As such - with the current semantics - I'm not sure it's important to be able to easily distinguish the two. I'd be happy to be convinced otherwise if you think it's important.
Aug 22 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 22 August 2013 at 14:39:59 UTC, Jakob Ovrum wrote:
 I don't think it's correct or useful to label one as 
 compile-time and the other as runtime. I think the mutability 
 or immutability of the expression tuple is an obvious result of 
 its lvalue-ish or rvalue-ish nature, respectively. As such - 
 with the current semantics - I'm not sure it's important to be 
 able to easily distinguish the two. I'd be happy to be 
 convinced otherwise if you think it's important.
I don't know either :) I am just trying to find some order in existing scheme. What frustrates me most in expression sequences being both runtime and compile-time is that compile-time still can act as if they are almost types: alias a = TypeTuple!(1, 2); // ok auto b = TypeTuple!(1, 2); // also ok! Isn't it the only entity in the whole language that can be used in type context (alias) and value context (initializer) at the same time?
Aug 22 2013
next sibling parent reply "Meta" <jared771 gmail.com> writes:
One question, wasn't the fact that "template Test(T...)" can 
accept literals as well as types originally a bug? Or am I 
thinking of "template Test(alias T)"?
Aug 22 2013
parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 22 August 2013 at 15:01:23 UTC, Meta wrote:
 One question, wasn't the fact that "template Test(T...)" can 
 accept literals as well as types originally a bug? Or am I 
 thinking of "template Test(alias T)"?
Well it is necessity that comes from the fact that it denotes "variadic template argument list". If this is legal (and it is): template Test(int N, T) { } than variadic list must accept both too.
Aug 22 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 08/22/13 16:57, Dicebot wrote:
 On Thursday, 22 August 2013 at 14:39:59 UTC, Jakob Ovrum wrote:
 I don't think it's correct or useful to label one as compile-time and the
other as runtime. I think the mutability or immutability of the expression
tuple is an obvious result of its lvalue-ish or rvalue-ish nature,
respectively. As such - with the current semantics - I'm not sure it's
important to be able to easily distinguish the two. I'd be happy to be
convinced otherwise if you think it's important.
I don't know either :) I am just trying to find some order in existing scheme. What frustrates me most in expression sequences being both runtime and compile-time is that compile-time still can act as if they are almost types: alias a = TypeTuple!(1, 2); // ok auto b = TypeTuple!(1, 2); // also ok! Isn't it the only entity in the whole language that can be used in type context (alias) and value context (initializer) at the same time?
It's not a "type context". That alias declaration only creates another name ("alias"). int v; alias a = v; auto b = v; Which btw means that introducing /just/ a new tuple syntax w/o other changes would make the equivalent of that first 'a' declaration illegal, for the same reasons that make alias c = 1; not valid right now. But allowing literals here shouldn't be a problem (allowing /all/ rvalues would be, at least w/o a working lifetime system). artur
Aug 23 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 22 August 2013 at 13:43:47 UTC, Dicebot wrote:
 On Thursday, 22 August 2013 at 13:39:25 UTC, Jakob Ovrum wrote:
 I'm fine with any name but would like to point out that it's 
 probably essential that the new name allows for the 
 distinction between what we currently call type tuples and 
 expression/mixed tuples. The latter are not so important to 
 distinguish, but type tuples have the privilege of being able 
 to declare an expression tuple:

    TypeTuple!(int, string) myExpressionTuple;
    myExpressionTuple[0] = 42;
    myExpressionTuple[1] = "foo";
    // etc
One extra source of confusion is that "expression tuple" was often used for TypeTuple!(42, "foo") ones, not for runtime instances. Those two are very different in D. That is why I am saying one name is not enough and some classification is needed.
That is in the doc : "A Tuple whose elements consist entirely of types is called a TypeTuple. A Tuple whose elements consist entirely of expressions is called an ExpressionTuple. " http://dlang.org/template.html#TemplateTupleParameter
Aug 22 2013
prev sibling parent "Don" <x nospam.com> writes:
On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu
wrote:
 There's an inordinate amount of confusion around what we 
 currently call "type tuple" (embodied in std's TypeTuple). I've 
 been furious immediately as I got word that Walter called it 
 that way, and it hasn't failed to make everybody else feel the 
 same over the years.

 So: shall we use "template pack" going forward exclusively 
 whenever we refer to that stuff? That way we can unambiguously 
 use "tuple" for "value tuples, i.e. like mini-structs that 
 group values together".

 Destroy. I mean criticize.



 Andrei
The minimal name change would be: TypeSystemTuple (or is that TypesystemTuple?). Inside the type system, it is actually a tuple. It's implemented as a tuple inside the compiler, which is why Walter probably gave it that confusing name in the first place. It's a tuple in the compiler world, but that is not exactly the same as a tuple in the programmer's world. The fact that it is a tuple inside the compiler, is the reason that it shares so many characteristics with tuples. It is a tuple of type system entities (which does include things other than types). You can use that to create a run-time tuple.
Aug 23 2013