digitalmars.D - Pair literal for D language

Uranuz (39/39) Jun 26 2014 Very often I use associative array as the simple syntactic way of

bearophile (4/5) Jun 26 2014 Built-in tuple literals: good. Just pair literals: no, thanks.

Uranuz (6/6) Jun 26 2014 Thanks for response. I was thinking that adding new statement for

H. S. Teoh via Digitalmars-d (12/17) Jun 26 2014 Note that the word "tuple" in D is used to refer to two very different

deadalnix (4/29) Jun 26 2014 We'd make a step forward when we stop calling type tuples type

H. S. Teoh via Digitalmars-d (6/30) Jun 26 2014 I agree, but that's what they're called in the compiler source code, so

Dicebot (4/7) Jun 27 2014 Most people never look in compiler source code so lets pretend it

H. S. Teoh via Digitalmars-d (6/12) Jun 27 2014 On the whole, I support it. But somebody needs to make the PR, otherwise

Dicebot (7/21) Jun 27 2014 On my todo list, matter of prerequisites :(

Mason McGill (11/11) Jun 27 2014 I like DIP54 and I think the work on fixing tuples is awesome,

Tofu Ninja (3/4) Jun 27 2014 I think StaticList is the clearest, really makes it obvious what

deadalnix (2/6) Jun 27 2014 Static already mean everything, please no.

H. S. Teoh via Digitalmars-d (7/15) Jun 27 2014 Yeah, "static" already means way too many things in D. Let's not

Dicebot (6/17) Jun 28 2014 Because it is defined by template argument list and has exactly

Mason McGill (4/22) Jun 28 2014 Understood. I was just expressing my initial impression: that it

Timon Gehr (13/35) Jun 28 2014 That would be strange, but it isn't.

Mason McGill (6/48) Jun 29 2014 I understand, but I was talking about `var` being referred to as

Dicebot (4/8) Jun 29 2014 Why do you expect template argument list to be used only as

Tofu Ninja (5/14) Jun 29 2014 Your argument is nice and all, but can you really not see how

Dicebot (4/20) Jun 29 2014 I am honestly trying to understand people thought flow goes that

deadalnix (2/5) Jun 29 2014 Quite frankly any name is better than that except tuple.

Dicebot (5/9) Jun 28 2014 My hope is that having such surprising name will exactly motivate

H. S. Teoh via Digitalmars-d (13/22) Jun 28 2014 We've had this discussion before (and not just once), that "tuple" is a

Dicebot (5/16) Jun 28 2014 I know. It will take quite some time to finish though and

deadalnix (4/24) Jun 28 2014 You keep repeating that, but people keep being confused. It is

Dicebot (5/10) Jun 28 2014 I don't think any name is possible which don't keep someone

deadalnix (4/10) Jun 28 2014 http://www.reddit.com/r/programming/comments/298vtt/dconf_2014_panel_wit...

Timon Gehr (10/20) Jun 28 2014 Well, there are many things that could be considered tuples:

deadalnix (4/30) Jun 28 2014 That is certainly a useful language construct (what Dicebot call

Ary Borenszweig (3/35) Jun 28 2014 I think it's common:

safety0ff (12/14) Jun 28 2014 Actually, that section is about normal tuples, there is no

Timon Gehr (11/27) Jun 28 2014 There's no equivalent. No auto-expansion in Julia. (They do have

Jacob Carlborg (6/9) Jun 28 2014 I would like some form of anonymous struct, with some kind of pattern

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

"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

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

"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

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

"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

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

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

D Programming

C/C++ Programming

Other

digitalmars.D - Pair literal for D language