www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pair literal for D language

reply "Uranuz" <neuranuz gmail.com> writes:
Very often I use associative array as the simple syntactic way of 
representing of pairs of some values. But AAs are slightly 
complicated for this task and they don't preserve order inside 
it. I could use some struct for example

struct P(T, N)
{
    T first;
    N second;
}

and write something like

auto pairs = [ P(1, "one"), P(2, "two"), P(3, "three") ];

But this looking not very pleasant and it's not obvious what P 
is, but writing words Pair is verbose. So what I was thinking 
about it could we have some syntactic sugar for this simple type 
of data. In my experience of using D I needed it very often and 
emulated it with AAs. Problem is that I don't always need all the 
features of it (I meen searching by hash). But syntax like

1. auto pairs = [ 1: "one", 2: "two", 3: "three" ];
2. auto pairs = [ 1 => "one", 2 => "two", 3 => "three" ];
or
3. auto pairs = [ 1 -> "one", 2 -> "two", 3 -> "three" ];
4. something else

It could be useful in my opinion. Resulting type for this could 
be a simple struct with 'first' and 'second' properties and index 
operators [0], [1].

Also this could be expanded to 'threes' of values and etc
auto threes = [ 1 -> "one" -> "I", 2 -> "two" -> "II", 3 -> 
"three" -> "III" ];

In process of writing of this letter I remembered about tuple 
literal proposal. It can also help to solve this problem, because 
we can make it not verbose and also it will propose standard 
struct name for it. For example it could look like this:

auto pairs = [ t{1, "one"} , t{2, "two"}, t{3, "three"} ] ;
auto threes = [ t{1, "one", "I"} , t{2, "two", "II"}, t{3, 
"three", "III"} ] ;

In this code I assume that t{} is tuple literal. But all these 
bracers are not that elegant as single -> or => or another 
operator.

I'd like to see any comments
Jun 26 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Uranuz:

 I'd like to see any comments

Built-in tuple literals: good. Just pair literals: no, thanks. Bye, bearophile
Jun 26 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-06-26 23:16, H. S. Teoh via Digitalmars-d wrote:

 Note that the word "tuple" in D is used to refer to two very different
 things. What you want is essentially an anonymous struct, and should be
 adequately covered by std.typecons.tuple.

I would like some form of anonymous struct, with some kind of pattern matching on the fields [1]. [1] http://forum.dlang.org/thread/kfbnuc$1cro$1 digitalmars.com -- /Jacob Carlborg
Jun 28 2014
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/28/2014 06:11 PM, Mason McGill wrote:
 On Saturday, 28 June 2014 at 09:15:29 UTC, Dicebot wrote:
 On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
 I like DIP54 and I think the work on fixing tuples is awesome, but I
 have 1 nit-picky question: why is it called "TemplateArgumentList"
 when it's not always used as template arguments?

  void func(string, string) { }

  TypeTuple!(string, string) var;
  var[0] = "I'm nobody's ";
  var[1] = "template argument!";
  f(var);

 Why not a name that emphasizes the entity's semantics, like
 "StaticList"/"ExpandingList"/"StaticTuple"/"ExpandingTuple"?

Because it is defined by template argument list and has exactly the same semantics as one. And semantics are unique and obscure enough that no other name can express it precisely.

Understood. I was just expressing my initial impression: that it seemed strange that a symbol declared as a `TemplateArgumentList` was neither passed nor received as template arguments.

That would be strange, but it isn't. TypeTuple!(string, string) var; ^~~~~~~~~~~~~~~~~ passed here alias TypeTuple(T...)=T; <- aliased here ^~~~ received here Hence: TypeTuple!(string, string) var; ^~~~~~~~~~~~~~~~~~~~~~~~~~ this is actually the template argument list that was passed In any case, I just call it 'Seq'.
Jun 28 2014
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/28/2014 09:40 PM, deadalnix wrote:
 On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via Digitalmars-d
 wrote:
 We'd make a step forward when we stop calling type tuples type tuples.
 They are not tuples, and do not contain (only) types.

I agree, but that's what they're called in the compiler source code, so it's kinda hard to call them something else.

http://www.reddit.com/r/programming/comments/298vtt/dconf_2014_panel_with_walter_bright_and_andrei/ciiw5zb :(

Well, there are many things that could be considered tuples: void foo(int x, int y){ // ^~~~~~~~~~~~~~ } void main(){ foo(1,2); // ^~~~~ } :o)
Jun 28 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 6/28/14, 6:49 PM, deadalnix wrote:
 On Saturday, 28 June 2014 at 21:22:14 UTC, Timon Gehr wrote:
 On 06/28/2014 09:40 PM, deadalnix wrote:
 On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via Digitalmars-d
 wrote:
 We'd make a step forward when we stop calling type tuples type tuples.
 They are not tuples, and do not contain (only) types.

I agree, but that's what they're called in the compiler source code, so it's kinda hard to call them something else.

http://www.reddit.com/r/programming/comments/298vtt/dconf_2014_panel_with_walter_bright_and_andrei/ciiw5zb :(

Well, there are many things that could be considered tuples: void foo(int x, int y){ // ^~~~~~~~~~~~~~ } void main(){ foo(1,2); // ^~~~~ } :o)

That is certainly a useful language construct (what Dicebot call TemplateArgumentList, but as we see, there s no template in this sample code), but certainly not what is commonly called a tuple.

I think it's common: http://julia.readthedocs.org/en/latest/manual/types/#tuple-types
Jun 28 2014
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 06/29/2014 12:42 AM, safety0ff wrote:
 On Saturday, 28 June 2014 at 21:51:17 UTC, Ary Borenszweig wrote:
 I think it's common:
 http://julia.readthedocs.org/en/latest/manual/types/#tuple-types

Actually, that section is about normal tuples, there is no distinction between normal tuples and type tuples in julia. From Julia repl: julia> typeof((1,1)) (Int64,Int64) julia> typeof(typeof((1,1))) (DataType,DataType) julia> typeof((Int64,1)) (DataType,Int64) So the equivalent

There's no equivalent. No auto-expansion in Julia. (They do have explicit expansion, but an expanded tuple is not an object in its own right.)
 to our TypeTuple is a normal tuple containing DataType
 types.

TypeTuple!(int,string) t; is basically the same as int __t_field_0; string __t_field_1; alias t=TypeTuple!(__t_field_0,__t_field_1); I.e. D conflates TypeTuple's of types with types of TypeTuples just as Julia conflates types of tuples with tuples of types.
Jun 28 2014
prev sibling next sibling parent reply "Uranuz" <neuranuz gmail.com> writes:
Thanks for response. I was thinking that adding new statement for 
such feature is not very good too. Is there any recent 
discussions about tuble literals. There is proposal in wiki but I 
don't know if it will be accepted or not for some time. For now 
seems like it's better to alias tuple and use it instead of 
literal
Jun 26 2014
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Jun 28, 2014 at 05:00:09AM +0000, deadalnix via Digitalmars-d wrote:
 On Saturday, 28 June 2014 at 03:01:12 UTC, Tofu Ninja wrote:
On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
"StaticList"/"ExpandingList"/"StaticTuple"/"ExpandingTuple"?

I think StaticList is the clearest, really makes it obvious what it is.

Static already mean everything, please no.

Yeah, "static" already means way too many things in D. Let's not overload it anymore than it already is. What about CTList? (CT for Compile-Time) T -- For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos.
Jun 27 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jun 26, 2014 at 09:08:24PM +0000, Uranuz via Digitalmars-d wrote:
 Thanks for response. I was thinking that adding new statement for such
 feature is not very good too. Is there any recent discussions about
 tuble literals. There is proposal in wiki but I don't know if it will
 be accepted or not for some time. For now seems like it's better to
 alias tuple and use it instead of literal

Note that the word "tuple" in D is used to refer to two very different things. What you want is essentially an anonymous struct, and should be adequately covered by std.typecons.tuple. Most of the tuple proposals, however, also seek to unify the functionality of std.typecons.tuple with the so-called "compile-time tuples" or "type tuples", which are a rather different beast (though they do overlap with std.typecons.tuple somewhat). This is a lot more complex, and probably beyond what you need anyway. T -- I am not young enough to know everything. -- Oscar Wilde
Jun 26 2014
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Jun 28, 2014 at 09:15:18PM +0000, Dicebot via Digitalmars-d wrote:
 On Saturday, 28 June 2014 at 16:11:15 UTC, Mason McGill wrote:
Understood. I was just expressing my initial impression: that it
seemed strange that a symbol declared as a `TemplateArgumentList` was
neither passed nor received as template arguments.

My hope is that having such surprising name will exactly motivate people to figure out what it is before having any false expectations and assumptions (like we have right now with all those `SomethingTuple`)

We've had this discussion before (and not just once), that "tuple" is a misnomer, yada yada yada, but until somebody files a PR to change this, things are just going to continue to remain the same. So I'd say, whatever name you think is best in place of tuple, just go for it and file a PR. Then we can bikeshed over the exact name once things get going. T -- One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"
Jun 28 2014
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 June 2014 at 21:25:31 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 We've had this discussion before (and not just once), that 
 "tuple" is a
 misnomer, yada yada yada, but until somebody files a PR to 
 change this,
 things are just going to continue to remain the same. So I'd 
 say,
 whatever name you think is best in place of tuple, just go for 
 it and
 file a PR. Then we can bikeshed over the exact name once things 
 get
 going.

I know. It will take quite some time to finish though and casually using term "tuple" all the time does not help - pretty much anything is better.
Jun 28 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 26 June 2014 at 21:17:45 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Thu, Jun 26, 2014 at 09:08:24PM +0000, Uranuz via 
 Digitalmars-d wrote:
 Thanks for response. I was thinking that adding new statement 
 for such
 feature is not very good too. Is there any recent discussions 
 about
 tuble literals. There is proposal in wiki but I don't know if 
 it will
 be accepted or not for some time. For now seems like it's 
 better to
 alias tuple and use it instead of literal

Note that the word "tuple" in D is used to refer to two very different things. What you want is essentially an anonymous struct, and should be adequately covered by std.typecons.tuple. Most of the tuple proposals, however, also seek to unify the functionality of std.typecons.tuple with the so-called "compile-time tuples" or "type tuples", which are a rather different beast (though they do overlap with std.typecons.tuple somewhat). This is a lot more complex, and probably beyond what you need anyway. T

We'd make a step forward when we stop calling type tuples type tuples. They are not tuples, and do not contain (only) types.
Jun 26 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jun 27, 2014 at 05:35:40AM +0000, deadalnix via Digitalmars-d wrote:
 On Thursday, 26 June 2014 at 21:17:45 UTC, H. S. Teoh via Digitalmars-d
 wrote:
On Thu, Jun 26, 2014 at 09:08:24PM +0000, Uranuz via Digitalmars-d wrote:
Thanks for response. I was thinking that adding new statement for
such feature is not very good too. Is there any recent discussions
about tuble literals. There is proposal in wiki but I don't know if
it will be accepted or not for some time. For now seems like it's
better to alias tuple and use it instead of literal

Note that the word "tuple" in D is used to refer to two very different things. What you want is essentially an anonymous struct, and should be adequately covered by std.typecons.tuple. Most of the tuple proposals, however, also seek to unify the functionality of std.typecons.tuple with the so-called "compile-time tuples" or "type tuples", which are a rather different beast (though they do overlap with std.typecons.tuple somewhat). This is a lot more complex, and probably beyond what you need anyway. T

We'd make a step forward when we stop calling type tuples type tuples. They are not tuples, and do not contain (only) types.

I agree, but that's what they're called in the compiler source code, so it's kinda hard to call them something else. T -- Guns don't kill people. Bullets do.
Jun 26 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 I agree, but that's what they're called in the compiler source 
 code, so
 it's kinda hard to call them something else.

Most people never look in compiler source code so lets pretend it does not exist ;) http://wiki.dlang.org/DIP54
Jun 27 2014
prev sibling next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jun 27, 2014 at 06:32:34PM +0000, Dicebot via Digitalmars-d wrote:
 On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via Digitalmars-d wrote:
I agree, but that's what they're called in the compiler source code,
so it's kinda hard to call them something else.

Most people never look in compiler source code so lets pretend it does not exist ;) http://wiki.dlang.org/DIP54

On the whole, I support it. But somebody needs to make the PR, otherwise nothing will happen. ;-) T -- People tell me that I'm skeptical, but I don't believe it.
Jun 27 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 27 June 2014 at 19:11:45 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 On Fri, Jun 27, 2014 at 06:32:34PM +0000, Dicebot via 
 Digitalmars-d wrote:
 On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via 
 Digitalmars-d wrote:
I agree, but that's what they're called in the compiler 
source code,
so it's kinda hard to call them something else.

Most people never look in compiler source code so lets pretend it does not exist ;) http://wiki.dlang.org/DIP54

On the whole, I support it. But somebody needs to make the PR, otherwise nothing will happen. ;-)

On my todo list, matter of prerequisites :( http://wiki.dlang.org/DIP63 is currently a blocker (and the thing I am working on right now), https://github.com/D-Programming-Language/dmd/pull/3651 is also very desirable. And merging each PR is a battle of its own.
Jun 27 2014
prev sibling next sibling parent "Mason McGill" <mmcgill caltech.edu> writes:
I like DIP54 and I think the work on fixing tuples is awesome, 
but I have 1 nit-picky question: why is it called 
"TemplateArgumentList" when it's not always used as template 
arguments?

   void func(string, string) { }

   TypeTuple!(string, string) var;
   var[0] = "I'm nobody's ";
   var[1] = "template argument!";
   f(var);

Why not a name that emphasizes the entity's semantics, like 
"StaticList"/"ExpandingList"/"StaticTuple"/"ExpandingTuple"?
Jun 27 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
 "StaticList"/"ExpandingList"/"StaticTuple"/"ExpandingTuple"?

I think StaticList is the clearest, really makes it obvious what it is.
Jun 27 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 28 June 2014 at 03:01:12 UTC, Tofu Ninja wrote:
 On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
 "StaticList"/"ExpandingList"/"StaticTuple"/"ExpandingTuple"?

I think StaticList is the clearest, really makes it obvious what it is.

Static already mean everything, please no.
Jun 27 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
 I like DIP54 and I think the work on fixing tuples is awesome, 
 but I have 1 nit-picky question: why is it called 
 "TemplateArgumentList" when it's not always used as template 
 arguments?

   void func(string, string) { }

   TypeTuple!(string, string) var;
   var[0] = "I'm nobody's ";
   var[1] = "template argument!";
   f(var);

 Why not a name that emphasizes the entity's semantics, like 
 "StaticList"/"ExpandingList"/"StaticTuple"/"ExpandingTuple"?

Because it is defined by template argument list and has exactly the same semantics as one. And semantics are unique and obscure enough that no other name can express it precisely. 'StaticList' is what you may have wanted it to be but not what it is.
Jun 28 2014
prev sibling next sibling parent "Mason McGill" <mmcgill caltech.edu> writes:
On Saturday, 28 June 2014 at 09:15:29 UTC, Dicebot wrote:
 On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
 I like DIP54 and I think the work on fixing tuples is awesome, 
 but I have 1 nit-picky question: why is it called 
 "TemplateArgumentList" when it's not always used as template 
 arguments?

  void func(string, string) { }

  TypeTuple!(string, string) var;
  var[0] = "I'm nobody's ";
  var[1] = "template argument!";
  f(var);

 Why not a name that emphasizes the entity's semantics, like 
 "StaticList"/"ExpandingList"/"StaticTuple"/"ExpandingTuple"?

Because it is defined by template argument list and has exactly the same semantics as one. And semantics are unique and obscure enough that no other name can express it precisely.

Understood. I was just expressing my initial impression: that it seemed strange that a symbol declared as a `TemplateArgumentList` was neither passed nor received as template arguments.
Jun 28 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 28 June 2014 at 09:15:29 UTC, Dicebot wrote:
 On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
 I like DIP54 and I think the work on fixing tuples is awesome, 
 but I have 1 nit-picky question: why is it called 
 "TemplateArgumentList" when it's not always used as template 
 arguments?

  void func(string, string) { }

  TypeTuple!(string, string) var;
  var[0] = "I'm nobody's ";
  var[1] = "template argument!";
  f(var);

 Why not a name that emphasizes the entity's semantics, like 
 "StaticList"/"ExpandingList"/"StaticTuple"/"ExpandingTuple"?

Because it is defined by template argument list and has exactly the same semantics as one. And semantics are unique and obscure enough that no other name can express it precisely.

You keep repeating that, but people keep being confused. It is time to admit defeat.
 'StaticList' is what you may have wanted it to be but not what 
 it is.

It is whatever we choose it is.
Jun 28 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via 
Digitalmars-d wrote:
 We'd make a step forward when we stop calling type tuples type 
 tuples.
 They are not tuples, and do not contain (only) types.

I agree, but that's what they're called in the compiler source code, so it's kinda hard to call them something else.

http://www.reddit.com/r/programming/comments/298vtt/dconf_2014_panel_with_walter_bright_and_andrei/ciiw5zb :(
Jun 28 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 June 2014 at 19:39:35 UTC, deadalnix wrote:
 You keep repeating that, but people keep being confused. It is 
 time to admit defeat.

I don't think any name is possible which don't keep someone confused - as long as this entity behaves as it does.
 'StaticList' is what you may have wanted it to be but not what 
 it is.

It is whatever we choose it is.

We can't change existing semantics even slightly, too interleaved with many language aspects.
Jun 28 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 28 June 2014 at 16:11:15 UTC, Mason McGill wrote:
 Understood. I was just expressing my initial impression: that 
 it seemed strange that a symbol declared as a 
 `TemplateArgumentList` was neither passed nor received as 
 template arguments.

My hope is that having such surprising name will exactly motivate people to figure out what it is before having any false expectations and assumptions (like we have right now with all those `SomethingTuple`)
Jun 28 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 28 June 2014 at 21:22:14 UTC, Timon Gehr wrote:
 On 06/28/2014 09:40 PM, deadalnix wrote:
 On Friday, 27 June 2014 at 05:45:19 UTC, H. S. Teoh via 
 Digitalmars-d
 wrote:
 We'd make a step forward when we stop calling type tuples 
 type tuples.
 They are not tuples, and do not contain (only) types.

I agree, but that's what they're called in the compiler source code, so it's kinda hard to call them something else.

http://www.reddit.com/r/programming/comments/298vtt/dconf_2014_panel_with_walter_bright_and_andrei/ciiw5zb :(

Well, there are many things that could be considered tuples: void foo(int x, int y){ // ^~~~~~~~~~~~~~ } void main(){ foo(1,2); // ^~~~~ } :o)

That is certainly a useful language construct (what Dicebot call TemplateArgumentList, but as we see, there s no template in this sample code), but certainly not what is commonly called a tuple.
Jun 28 2014
prev sibling next sibling parent "safety0ff" <safety0ff.dev gmail.com> writes:
On Saturday, 28 June 2014 at 21:51:17 UTC, Ary Borenszweig wrote:
 I think it's common: 
 http://julia.readthedocs.org/en/latest/manual/types/#tuple-types

Actually, that section is about normal tuples, there is no distinction between normal tuples and type tuples in julia. From Julia repl: julia> typeof((1,1)) (Int64,Int64) julia> typeof(typeof((1,1))) (DataType,DataType) julia> typeof((Int64,1)) (DataType,Int64) So the equivalent to our TypeTuple is a normal tuple containing DataType types.
Jun 28 2014
prev sibling next sibling parent "Mason McGill" <mmcgill caltech.edu> writes:
On Saturday, 28 June 2014 at 21:12:06 UTC, Timon Gehr wrote:
 On 06/28/2014 06:11 PM, Mason McGill wrote:
 On Saturday, 28 June 2014 at 09:15:29 UTC, Dicebot wrote:
 On Friday, 27 June 2014 at 22:01:21 UTC, Mason McGill wrote:
 I like DIP54 and I think the work on fixing tuples is 
 awesome, but I
 have 1 nit-picky question: why is it called 
 "TemplateArgumentList"
 when it's not always used as template arguments?

 void func(string, string) { }

 TypeTuple!(string, string) var;
 var[0] = "I'm nobody's ";
 var[1] = "template argument!";
 f(var);

 Why not a name that emphasizes the entity's semantics, like
 "StaticList"/"ExpandingList"/"StaticTuple"/"ExpandingTuple"?

Because it is defined by template argument list and has exactly the same semantics as one. And semantics are unique and obscure enough that no other name can express it precisely.

Understood. I was just expressing my initial impression: that it seemed strange that a symbol declared as a `TemplateArgumentList` was neither passed nor received as template arguments.

That would be strange, but it isn't. TypeTuple!(string, string) var; ^~~~~~~~~~~~~~~~~ passed here alias TypeTuple(T...)=T; <- aliased here ^~~~ received here Hence: TypeTuple!(string, string) var; ^~~~~~~~~~~~~~~~~~~~~~~~~~ this is actually the template argument list that was passed In any case, I just call it 'Seq'.

I understand, but I was talking about `var` being referred to as a `TemplateArgumentList` when it's not used as such. It's used as an `ArgumentList`, just not a `TemplateArgumentList`. Cheers, Mason
Jun 29 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 29 June 2014 at 16:03:07 UTC, Mason McGill wrote:
 I understand, but I was talking about `var` being referred to as
 a `TemplateArgumentList` when it's not used as such. It's used 
 as
 an `ArgumentList`, just not a `TemplateArgumentList`.

Why do you expect template argument list to be used only as argument to templates? Anything that matches http://dlang.org/grammar#TemplateArgumentList can be called one.
Jun 29 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Sunday, 29 June 2014 at 16:09:15 UTC, Dicebot wrote:
 On Sunday, 29 June 2014 at 16:03:07 UTC, Mason McGill wrote:
 I understand, but I was talking about `var` being referred to 
 as
 a `TemplateArgumentList` when it's not used as such. It's used 
 as
 an `ArgumentList`, just not a `TemplateArgumentList`.

Why do you expect template argument list to be used only as argument to templates? Anything that matches http://dlang.org/grammar#TemplateArgumentList can be called one.

Your argument is nice and all, but can you really not see how calling it a TemplateArgumentList could cause confusion when it is not used as a template argument. We should be striving for clarity here.
Jun 29 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 29 June 2014 at 20:44:06 UTC, Tofu Ninja wrote:
 On Sunday, 29 June 2014 at 16:09:15 UTC, Dicebot wrote:
 On Sunday, 29 June 2014 at 16:03:07 UTC, Mason McGill wrote:
 I understand, but I was talking about `var` being referred to 
 as
 a `TemplateArgumentList` when it's not used as such. It's 
 used as
 an `ArgumentList`, just not a `TemplateArgumentList`.

Why do you expect template argument list to be used only as argument to templates? Anything that matches http://dlang.org/grammar#TemplateArgumentList can be called one.

Your argument is nice and all, but can you really not see how calling it a TemplateArgumentList could cause confusion when it is not used as a template argument. We should be striving for clarity here.

I am honestly trying to understand people thought flow goes that makes them expect such things :) That may help to come with better idea (no currently proposed name is any good)
Jun 29 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 29 June 2014 at 21:24:15 UTC, Dicebot wrote:
 I am honestly trying to understand people thought flow goes 
 that makes them expect such things :) That may help to come 
 with better idea (no currently proposed name is any good)

Quite frankly any name is better than that except tuple.
Jun 29 2014