digitalmars.D - s/type tuple/template pack/g please
- Andrei Alexandrescu (9/9) Aug 21 2013 There's an inordinate amount of confusion around what we currently call
- Meta (3/8) Aug 21 2013 Yes, let's make sure to avoid any undue confusion.
- Dicebot (6/24) Aug 21 2013 http://forum.dlang.org/post/lrycaqlrtwylhbxfifyz@forum.dlang.org
- monarch_dodra (7/16) Aug 21 2013 "template pack" isn't really clearer to me than "type tuple",
- Andrei Alexandrescu (5/18) Aug 21 2013 I agree. Let's have an epic debate once and for all for the right name,
- David Nadlinger (21/23) Aug 21 2013 Yes, we need do do something about this, and the sooner, the
- Atash (24/37) Aug 21 2013 My backpack isn't full of backs, though...
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (17/20) Aug 21 2013 TypeTuple can represent function parameter lists and array literal lists...
- Atash (22/38) Aug 22 2013 Under the assumption that the following was meant to be a
- Brad Anderson (9/13) Aug 21 2013 "Seq" is nice too because it has no baggage that comes with terms
- Andrei Alexandrescu (4/16) Aug 21 2013 "Seq" has the problem that it's not an actual word or phrase and as such...
- John Colvin (4/30) Aug 21 2013 Seeing as basically all the "talking" is actually typing, I don't
- Brad Anderson (8/34) Aug 21 2013 Nobody seems to know how to say "trie" either but it's successful
- Brad Anderson (14/25) Aug 21 2013 There are a lot of good names for it: Template Pack, Type
- Dicebot (3/8) Aug 21 2013 Please, nothing with "Type" in its name. How can you call a "type
- Andrei Alexandrescu (3/22) Aug 21 2013 We much more need to get "type" out of the name. Those aren't types.
- Meta (12/14) Aug 21 2013 I think this is part of the problem. Nobody can agree on what
- Andrei Alexandrescu (4/8) Aug 21 2013 They're not hard to classify. They are anything that can be passed to a
- Meta (8/13) Aug 21 2013 Maybe I'm splitting hairs, but that's what goes into them. Not
- dennis luehring (3/17) Aug 21 2013 what about "alias list", "alias sequence" - seems to be more in that
- captaindet (6/19) Aug 21 2013 abstract tuples they are.
- Jacob Carlborg (5/12) Aug 22 2013 We could call the built-in ones for "tuple" and typecons.Tuple for
- Jonathan M Davis (5/19) Aug 22 2013 Considering that std.typecons.Tuple actually acts like a full-on tuple (...
- Jacob Carlborg (13/16) Aug 22 2013 I don't know the exact definition of "tuple" but what have nesting to do...
- Brad Anderson (5/40) Aug 21 2013 Alright. I always found the Tuple part more confusing but I guess
- Andrei Alexandrescu (4/33) Aug 21 2013 "Tuple" needs to go as well, although that entity does look like a tuple...
- Brad Anderson (5/54) Aug 21 2013 Yeah, the name "tuple" isn't actually all that inaccurate. The
- David Nadlinger (5/6) Aug 21 2013 I think we should make sure to drop "type" from the name – to me,
- John Colvin (7/18) Aug 21 2013 I'd say go with Seq as has been suggested by some people.
- Regan Heath (26/34) Aug 22 2013 After reading the thread I think it might help to try to define the
- dennis luehring (7/41) Aug 22 2013 ~but~ an "alias sequence" item is different to an alias
- deadalnix (3/10) Aug 22 2013 Function literal are passed around via alias all over the place.
- Regan Heath (44/93) Aug 22 2013 That's not quite what I was trying to say.
- deadalnix (7/17) Aug 22 2013 Many people started to use the sequence term. I think we should
- Tommi (14/16) Aug 22 2013 I think it should be called either a "compile-time list" or a
- Tommi (3/4) Aug 22 2013 And if we go with "compile-time list", then we can follow the
- Regan Heath (5/9) Aug 22 2013 +1 I like this suggestion also.
- Michel Fortin (6/11) Aug 22 2013 Will .tupleof become .ctlistof?
- John Colvin (3/11) Aug 22 2013 strictly speaking I think it would be an alias list, so perhaps
- Tommi (2/10) Aug 22 2013 I think it could be .fieldsof
- deadalnix (3/11) Aug 22 2013 This feature should be dropped and provided as library using
- Timon Gehr (2/14) Aug 22 2013 How to bypass protection attributes?
- deadalnix (3/22) Aug 22 2013 compile time reflection should be able to do it. Discussion has
- Jakob Ovrum (31/41) Aug 22 2013 I'm fine with any name but would like to point out that it's
- Dicebot (5/15) Aug 22 2013 One extra source of confusion is that "expression tuple" was
- Jakob Ovrum (2/6) Aug 22 2013 They are one and the same.
- Dicebot (6/13) Aug 22 2013 Almost, but not completely. They share implementation and much of
- Jakob Ovrum (8/14) Aug 22 2013 I don't think it's correct or useful to label one as compile-time
- Dicebot (10/17) Aug 22 2013 I don't know either :) I am just trying to find some order in
- Meta (3/3) Aug 22 2013 One question, wasn't the fact that "template Test(T...)" can
- Dicebot (5/8) Aug 22 2013 Well it is necessity that comes from the fact that it denotes
- Artur Skawina (13/22) Aug 23 2013 It's not a "type context". That alias declaration only creates another
- deadalnix (5/21) Aug 22 2013 That is in the doc : "A Tuple whose elements consist entirely of
- Don (13/24) Aug 23 2013 The minimal name change would be:
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
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
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. Andreihttp://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
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
On 8/21/13 11:10 AM, monarch_dodra wrote:On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu wrote: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. AndreiThere'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
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
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. ;) DavidBlue!
Aug 21 2013
On 08/21/2013 11:40 AM, Atash wrote:I don't see wording 'template pack' being problematic, assuming thatthere'sreally 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
On Wednesday, 21 August 2013 at 18:50:30 UTC, Ali Çehreli wrote:On 08/21/2013 11:40 AM, Atash wrote:Under the assumption that the following was meant to be a counterpoint...I don't see wording 'template pack' being problematic,assuming that there'sreally no other way to use them but through templates (whichAFAIK theycan'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);^ 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
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
On 8/21/13 12:01 PM, Brad Anderson wrote:On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger wrote:"Seq" has the problem that it's not an actual word or phrase and as such is difficult to talk about. AndreiPersonally, 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
On Wednesday, 21 August 2013 at 19:19:35 UTC, Andrei Alexandrescu wrote:On 8/21/13 12:01 PM, Brad Anderson wrote:Seeing as basically all the "talking" is actually typing, I don't really see how this is a problem.On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger wrote:"Seq" has the problem that it's not an actual word or phrase and as such is difficult to talk about. AndreiPersonally, 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
On Wednesday, 21 August 2013 at 19:19:35 UTC, Andrei Alexandrescu wrote:On 8/21/13 12:01 PM, Brad Anderson wrote: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.On Wednesday, 21 August 2013 at 18:17:03 UTC, David Nadlinger wrote:"Seq" has the problem that it's not an actual word or phrase and as such is difficult to talk about. AndreiPersonally, 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
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. AndreiThere 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
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
On 8/21/13 11:21 AM, Brad Anderson wrote:On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu wrote:We much more need to get "type" out of the name. Those aren't types. AndreiThere'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. AndreiThere 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.
Aug 21 2013
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
On 8/21/13 11:36 AM, Meta wrote:On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu wrote:They're not hard to classify. They are anything that can be passed to a template. AndreiWe 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.
Aug 21 2013
On Wednesday, 21 August 2013 at 18:44:14 UTC, Andrei Alexandrescu wrote: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.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.
Aug 21 2013
Am 21.08.2013 20:36, schrieb Meta:On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu wrote:what about "alias list", "alias sequence" - seems to be more in that directory - but not 100%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
On 2013-08-21 13:36, Meta wrote:On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu 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. /detWe 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
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
On Thursday, August 22, 2013 09:21:05 Jacob Carlborg wrote:On 2013-08-21 21:48, captaindet 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. - Jonathan M Davisabstract 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.
Aug 22 2013
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
On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu wrote:On 8/21/13 11:21 AM, Brad Anderson wrote: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.On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu wrote:We much more need to get "type" out of the name. Those aren't types. AndreiThere'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. AndreiThere 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.
Aug 21 2013
On 8/21/13 11:44 AM, Brad Anderson wrote:On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu wrote:"Tuple" needs to go as well, although that entity does look like a tuple in some respects. AndreiOn 8/21/13 11:21 AM, Brad Anderson wrote: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.On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu wrote:We much more need to get "type" out of the name. Those aren't types. AndreiThere'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. AndreiThere 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.
Aug 21 2013
On Wednesday, 21 August 2013 at 18:45:49 UTC, Andrei Alexandrescu wrote:On 8/21/13 11:44 AM, Brad Anderson wrote: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.On Wednesday, 21 August 2013 at 18:26:42 UTC, Andrei Alexandrescu wrote:"Tuple" needs to go as well, although that entity does look like a tuple in some respects. AndreiOn 8/21/13 11:21 AM, Brad Anderson wrote: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.On Wednesday, 21 August 2013 at 17:53:21 UTC, Andrei Alexandrescu wrote:We much more need to get "type" out of the name. Those aren't types. AndreiThere'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. AndreiThere 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.
Aug 21 2013
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
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. AndreiI'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
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
Am 22.08.2013 12:05, schrieb Regan Heath:On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> 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?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
Aug 22 2013
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
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: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/On Wed, 21 Aug 2013 18:53:06 +0100, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:an alias is an real accessible symbol - not just an position in a sequence or am i wrong here?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
Aug 22 2013
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
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
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
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:+1 I like this suggestion also. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/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
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:Will .tupleof become .ctlistof? -- Michel Fortin michel.fortin michelf.ca http://michelf.caI 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
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:strictly speaking I think it would be an alias list, so perhaps .aliasListOn Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:Will .tupleof become .ctlistof?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
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:I think it could be .fieldsofOn Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:Will .tupleof become .ctlistof?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
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:This feature should be dropped and provided as library using compile time reflection.On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:Will .tupleof become .ctlistof?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
On 08/22/2013 03:07 PM, deadalnix wrote:On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:How to bypass protection attributes?On 2013-08-22 11:55:55 +0000, "Tommi" <tommitissari hotmail.com> said:This feature should be dropped and provided as library using compile time reflection.On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:Will .tupleof become .ctlistof?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
On Thursday, 22 August 2013 at 13:10:28 UTC, Timon Gehr wrote:On 08/22/2013 03:07 PM, deadalnix wrote:compile time reflection should be able to do it. Discussion has been raised many time.On Thursday, 22 August 2013 at 12:06:11 UTC, Michel Fortin wrote:How to bypass protection attributes?On 2013-08-22 11:55:55 +0000, "Tommi" <tommitissari hotmail.com> said:This feature should be dropped and provided as library using compile time reflection.On Thursday, 22 August 2013 at 11:37:53 UTC, Tommi wrote:Will .tupleof become .ctlistof?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
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
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"; // etcOne 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
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
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: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.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
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
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
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
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
On 08/22/13 16:57, Dicebot wrote:On Thursday, 22 August 2013 at 14:39:59 UTC, Jakob Ovrum wrote: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). arturI 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 23 2013
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: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#TemplateTupleParameterI'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"; // etcOne 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
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. AndreiThe 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