www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tuple/TypeTuple etc.

reply "John Colvin" <john.loughran.colvin gmail.com> writes:
Denis has been complaining about this for ages and I think it's 
worth doing something about.

Definitions:

std.typecons.Tuple
A bit like python's tuples. It's a heterogeneous collection of 
runtime values with compile-time determined types.

std.typetuple.TypeTuple
A heterogeneous *compile-time* collection of types, expressions 
and aliases.


Problems:

TypeTuple isn't just a typetuple, it's an everythingtuple. It's a 
terrible name that is confusing to newcomers (and even to people 
who've used D a lot but not delved in to the CT capabilities so 
much).

TypeTuple looks too much like Tuple. It's a totally different 
concept but the names are too similar.


Possible solutions:

1) rename TypeTuple in-place to something better. This is not a 
real option as it would break far too much code.

2) Introduce a new tuple constructor with a new name, and 
deprecate TypeTuple

2a) A whole new module, leaving std.typetuple as effectively an 
alias to the new module. Denis has a pull for this[1], which also 
adds new tuple constructors specialised for expressions.


I like Denis' pull request. It fixes the problem in a backwards 
compatible manner. However - as Jonathan points out in the 
comments - the naming is still a problem. GenericTuple, 
ExpressionTuple etc. all sound like they could be related to 
std.typecons.Tuple

So, we need a new name:
Sequence, ArgList or ParamList are possible suggestions.


A possible complete path to getting this sorted, using Sequence 
as an example:

1) Create a new module like in Denis' PR, called std.sequence and 
containing the template Sequence, equivalent to current 
std.typetuple.TypeTuple

1a) optional: include specific templates like TypeSequence and 
ExpressionSequence.

2) Leave std.typetuple as an alias to the new module, including 
alias TypeTuple = Sequence; Deprecate it.

3) std.traits.isTypeTuple becomes isTypeSequence and 
isExpressionTuple becomes isExpressionSequence.   Deprecated 
aliases from the old names are left for compatibility.

4) Change phobos over to using std.sequence (note that this is 
not required immediately, as there is 100% backwards 
compatibility).

The only remaining headache would be people getting confused by 
dmd spewing out complaints about tuple(blah, blah, blah), but 
that's a relatively minor concern.


P.S. please note that deprecating is not breaking, per se. 
Deprecations are just warnings by default. Also, although having 
compatibility aliases floating around is annoying, it's an 
unfortunate necessity if one wants to change things while not 
breaking everyone's code. I think it's a model we're going to 
have to get used to in order to be both flexible and reliable.

[1] https://github.com/D-Programming-Language/phobos/pull/780
Aug 16 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
John Colvin:


 Possible solutions:


My vote is for solution n.5:

Add the built-in t{} syntax to denote all kind of tuples.

Bye,
bearophile
Aug 16 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 16 August 2013 at 16:08:42 UTC, bearophile wrote:

 John Colvin:


 Possible solutions:


 My vote is for solution n.5:

 Add the built-in t{} syntax to denote all kind of tuples.

 Bye,
 bearophile


There was no number 5...

A builtin syntax would be cool, I agree.
Aug 16 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 16 August 2013 at 16:08:42 UTC, bearophile wrote:

 John Colvin:


 Possible solutions:


 My vote is for solution n.5:

 Add the built-in t{} syntax to denote all kind of tuples.


This. With an exception of "I don't care what syntax is".

There has been a thread in D.learn by Ali recently 
http://forum.dlang.org/post/kuk8uc$30th$1 digitalmars.com - it 
pretty much highlights there we have plenty issues with the very 
behavior of TypeTuple, not only naming.

I know we are very reluctant to do language changes but this 
continues to do more and more damage to the language - it 
requires extra costs to maintain Phobos properly, confuses 
newcomers and complicates language specification itself as new 
corner cases get attention.

What was the general attitude to http://wiki.dlang.org/DIP32 ?
Aug 16 2013
parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 16 August 2013 at 16:19:51 UTC, Dicebot wrote:

 Add the built-in t{} syntax to denote all kind of tuples.


 This. With an exception of "I don't care what syntax is".


/snip

 What was the general attitude to http://wiki.dlang.org/DIP32 ?


I don't like the "t".  I'd prefer just using parentheses, but I 
think there were readability problems that caused the DIP to end 
up with:

 "Basic () syntax, perhaps the cleanest, but can't be used:"


Though there's nothing else written about that.

The DIP itself, though, looks pretty good.

-Wyatt
Aug 16 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Wyatt:


 I don't like the "t".


I know. So far we haven't found a syntax that is technically 
acceptable (this means backwards compatible, etc), not too much 
onerous in some ways, and much better than t{} (but of course 
syntax is a bit subjective, so others can find other syntaxes 
acceptable. In such cases Python developer team discusses, they 
vote one or more times, and at the end the benevolent Python 
dictator Guido V. Rossum reads the discussions and vote results 
and expresses the final decision, his words are more or less 
final).
It's short, clear, has a precedent with q{}. I don't like it a 
lot, but it's way better than not having language support for 
tuples.



 I'd prefer just using parentheses, but I think there were 
 readability problems that caused the DIP to end up with:


More than just readability problems. They were discussed when 
Kenji presented the DIP 32 in this forum. Timon found a 
significant problem with the {} syntax.



 "Basic () syntax, perhaps the cleanest, but can't be used:"


 Though there's nothing else written about that.


I have added those parts and comparisons in the DIP :-)
http://wiki.dlang.org/?title=DIP32&action=history

If you think some comments are missing feel free to add them, 
it's a Wiki.

----------------------

Jonathan M Davis:


 Since the built-in tuples / std.typetuple.TypeTuple and 
 std.typecons.Tuple
 are fundamentally different, I don't see how you could possibly 
 combine the two
 in a single syntax. You'd need different syntaxes for each one.


You are right, they are different things, sorry.
But let's hypothesize there is only one syntax for both of them. 
What bad things are going to happen? Can't the compiler infer by 
itself what of the two kinds you want to use?

Bye,
bearophile
Aug 16 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 17, 2013 at 01:23:57AM +0200, bearophile wrote:
[...]

 ----------------------
 
 Jonathan M Davis:
 

Since the built-in tuples / std.typetuple.TypeTuple and
std.typecons.Tuple are fundamentally different, I don't see how you
could possibly combine the two in a single syntax. You'd need
different syntaxes for each one.


 
 You are right, they are different things, sorry.
 But let's hypothesize there is only one syntax for both of them.
 What bad things are going to happen? Can't the compiler infer by
 itself what of the two kinds you want to use?


[...]

The problem is that the compile-time tuples, let's call them CT-tuples,
can contain compile-time-only elements, like types, and also things like
integer literals and other compile-time values. But std.range.Tuple,
let's call them runtime-tuples (RT-tuples) can only contain runtime
values. So suppose you have code like this:

	template makeTuple(alias x, alias y) {


	}

	alias a1 = makeTuple!(int,string); // obviously a CT-tuple
	alias a2 = makeTuple!(int,123);    // also a CT-tuple
	alias a3 = makeTuple!(123,456);    // <-- what's this?

Is a3 a CT-tuple or an RT-tuple? I don't think it's possible for the
compiler to tell.

OTOH, thinking about it a bit more...  suppose we not only use the same
syntax for CT-tuples and RT-tuples, but make them the *same thing*, by
having the compiler turn a CT-tuple into an RT-tuple if you try to
perform runtime operations on it like assigning it to a variable. This
will fail if the CT-tuple contains types, obviously, but can it work in
other contexts? It seems like it might be possible. I'm not sure if it
will lead to problems with ambiguity.  Certainly, it would constitute a
non-trivial change to the language, which may have far-reaching
consequences.

One interesting effect is that t is an RT-tuple, then typeof(t) is a
CT-tuple, but since they're the same thing, then the type of a tuple is
another tuple. So there's a kind of curious symmetry going on here. I
don't know if this will lead somewhere interesting, or perhaps it may
lead to contradictions. Might be worth exploring... but I'd wager the
chances of this actually making it into the language are rather slim at
this point.


T

-- 
EMACS = Extremely Massive And Cumbersome System
Aug 16 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 17 August 2013 at 00:25:44 UTC, H. S. Teoh wrote:

 One interesting effect is that t is an RT-tuple, then typeof(t) 
 is a
 CT-tuple, but since they're the same thing, then the type of a 
 tuple is
 another tuple.


Currently it is not the case. typeof(tuple(1,2)) is 
Tuple!(int,int), not TypeTuple!(int, int). But 
typeof(TypeTuple(1,2)) is TypeTyple!(int, int) :)

As I have already said it is not really about RT vs CT, it is 
more like "pure abstraction" vs "ABI-meaningful type". 
std.typecons.Tuple is normal templated struct so it has a proper 
symbol name, mangling and defined ABI for parameter-passing. 
Built-in one is just a syntax sugar, it has no meaning across 
object file borders.
Aug 16 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 01:01:10 UTC, Dicebot wrote:

 Currently it is not the case. typeof(tuple(1,2)) is 
 Tuple!(int,int), not TypeTuple!(int, int). But 
 typeof(TypeTuple(1,2)) is TypeTyple!(int, int) :)


Whu?

There is no such type as TypeTuple!(int, int), it is completely 
aliased away to a builtin tuple.

Also, printing out types is actually rather misleading, as it 
chooses when to use or not use tuple() in annoying ways e.g. 
TypeTuple!(int, string) is (int, string) but TypeTuple!(int, 3) 
is tuple(int, 3)   Either they are both tuples, or neither is.

To the best of my knowledge, there is only this:

1) collections of items, called tuples. They can contain pretty 
much anything you want, as long it's available at compile-time.
They are ***not types***. If and only if a tuple contains only 
types, the tuple itself is a type. This is often referred to as a 
type-tuple. In current D, tuples of all varieties are created by 
variadic template parameters.*

2) instantiations of type-tuples. These are a collection of 
runtime values, individually accessible by indexing or foreach 
iteration. std.typecons.Tuple is a wrapper around one of these 
providing some extra functionality.

*std.typetuple.TypeTuple only exists to provide convenient syntax 
for this.
Aug 17 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 17 August 2013 at 11:43:09 UTC, John Colvin wrote:

 On Saturday, 17 August 2013 at 01:01:10 UTC, Dicebot wrote:

 Currently it is not the case. typeof(tuple(1,2)) is 
 Tuple!(int,int), not TypeTuple!(int, int). But 
 typeof(TypeTuple(1,2)) is TypeTyple!(int, int) :)


 Whu?

 There is no such type as TypeTuple!(int, int), it is completely 
 aliased away to a builtin tuple.


Yeah but there is no syntax for them so I am using TypeTuple for 
unambiguity. pragma(msg) will print (int, int) for it.


 Also, printing out types is actually rather misleading, as it 
 chooses when to use or not use tuple() in annoying ways e.g. 
 TypeTuple!(int, string) is (int, string) but TypeTuple!(int, 3) 
 is tuple(int, 3)   Either they are both tuples, or neither is.


They are two types of built-in tuples - pure type tuples and 
expression/mixed tuples. typeof expression tuple is type tuple. 
Those have same syntax but slightly different semantics.


 To the best of my knowledge, there is only this:

 1) collections of items, called tuples. They can contain pretty 
 much anything you want, as long it's available at compile-time.
 They are ***not types***. If and only if a tuple contains only 
 types, the tuple itself is a type. This is often referred to as 
 a type-tuple. In current D, tuples of all varieties are created 
 by variadic template parameters.*


All true but last statement. They are not "created" anywhere, 
this is simply most convenient way to capture built-in tuple in a 
form usable by user code.


 2) instantiations of type-tuples. These are a collection of 
 runtime values, individually accessible by indexing or foreach 
 iteration. std.typecons.Tuple is a wrapper around one of these 
 providing some extra functionality.


As far as I can observe, instantiations of type tuples are 
expression tuples. And std.typecons.Tuple is completely different 
beast, it simply a template struct.

See example:

import std.typetuple;
import std.typecons;
import std.stdio;

void main()
{
	alias TT = TypeTuple!(int, string);
	enum ET = TypeTuple!(2, "2");
	TT twoVars; twoVars[0] = 2; twoVars[1] = "2";
	writeln(typeid(typeof(twoVars)));
	writeln(twoVars);
	writeln(typeid(typeof(ET)));
	writeln(ET);
	auto different = tuple(2, "2");
	writeln(typeid(typeof(different)));
	writeln(different);
	writeln(__traits(allMembers, typeof(different)));
}

------------------------

(int,immutable(char)[])
22
(int,immutable(char)[])
22
std.typecons.Tuple!(int, string).Tuple
Tuple!(int, string)(2, "2")
parseSpecsFieldSpecfieldSpecsextractTypeextractNameinjectNamedFieldssliceSpecsexpandSpecisCompatibleTuplesTypesexpand_0_1fieldat__ctoropEqualsopCmpopAssign_workaround4424slicelengthtoString_expand_field_0_expand_field_1

http://dpaste.dzfl.pl/b98d8537
Aug 17 2013
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 12:37:23 UTC, Dicebot wrote:

 On Saturday, 17 August 2013 at 11:43:09 UTC, John Colvin wrote:

 On Saturday, 17 August 2013 at 01:01:10 UTC, Dicebot wrote:

 Currently it is not the case. typeof(tuple(1,2)) is 
 Tuple!(int,int), not TypeTuple!(int, int). But 
 typeof(TypeTuple(1,2)) is TypeTyple!(int, int) :)


 Whu?

 There is no such type as TypeTuple!(int, int), it is 
 completely aliased away to a builtin tuple.


 Yeah but there is no syntax for them so I am using TypeTuple 
 for unambiguity. pragma(msg) will print (int, int) for it.


ok, fair enough.


 Also, printing out types is actually rather misleading, as it 
 chooses when to use or not use tuple() in annoying ways e.g. 
 TypeTuple!(int, string) is (int, string) but TypeTuple!(int, 
 3) is tuple(int, 3)   Either they are both tuples, or neither 
 is.


 They are two types of built-in tuples - pure type tuples and 
 expression/mixed tuples. typeof expression tuple is type tuple. 
 Those have same syntax but slightly different semantics.


Not quite, there are pure type-tuples (can be used as a type), 
pure expression-tuples (can be assigned to) and mixed tuples. But 
then there's also aliases...
	int a;
	auto b = TypeTuple!(a);
	b[0] = 3;
	assert(a == 0);  //passes
clearly b is an instantiation of a typetuple (or an 
expression-tuple, as you point out), but what is actually going 
on in it's initialisation?


 To the best of my knowledge, there is only this:

 1) collections of items, called tuples. They can contain 
 pretty much anything you want, as long it's available at 
 compile-time.
 They are ***not types***. If and only if a tuple contains only 
 types, the tuple itself is a type. This is often referred to 
 as a type-tuple. In current D, tuples of all varieties are 
 created by variadic template parameters.*


 All true but last statement. They are not "created" anywhere, 
 this is simply most convenient way to capture built-in tuple in 
 a form usable by user code.


That's what i mean by created. I deliberated over what word to 
use there for quite a while, but perhaps "capture" is better. 
Either way, you've got some ct stuff and you want to group it 
together in to a tuple, variadic template parameters is the way 
to do it.


 2) instantiations of type-tuples. These are a collection of 
 runtime values, individually accessible by indexing or foreach 
 iteration. std.typecons.Tuple is a wrapper around one of these 
 providing some extra functionality.


 As far as I can observe, instantiations of type tuples are 
 expression tuples.


That's an interesting way of looking at it. I didn't realise one 
could do this:
	auto ET = TypeTuple!(2, "2");
	ET[0] = 5;   //perfectly fine


 And std.typecons.Tuple is completely different beast, it simply 
 a template struct.


Yes, as I said: It's a wrapper around an instantiation of a 
type-tuple.



Every time I think I understand this, there's more...
Aug 17 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 17 August 2013 at 13:55:10 UTC, John Colvin wrote:

 And std.typecons.Tuple is completely different beast, it 
 simply a template struct.


 Yes, as I said: It's a wrapper around an instantiation of a 
 type-tuple.


By that logic every single possible template with variadic 
parameters is wrapper around instantiation of type tuple. 
std.typecons.Tuple does not store expression tuple inside so I 
don't think it is legal to call it a "wrapper". Simply 
pseudo-anonymous struct with pseudo-anonymous fields.
Aug 17 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/17/2013 04:04 PM, Dicebot wrote:

 On Saturday, 17 August 2013 at 13:55:10 UTC, John Colvin wrote:

 And std.typecons.Tuple is completely different beast, it simply a
 template struct.


 Yes, as I said: It's a wrapper around an instantiation of a type-tuple.


 By that logic every single possible template with variadic parameters is
 wrapper around instantiation of type tuple. std.typecons.Tuple does not
 store expression tuple inside so I don't think it is legal to call it a
 "wrapper". Simply pseudo-anonymous struct with pseudo-anonymous fields.


std.typecons.Tuple!(...).field is an "expression tuple".
Aug 17 2013
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 14:04:21 UTC, Dicebot wrote:

 On Saturday, 17 August 2013 at 13:55:10 UTC, John Colvin wrote:

 And std.typecons.Tuple is completely different beast, it 
 simply a template struct.


 Yes, as I said: It's a wrapper around an instantiation of a 
 type-tuple.


 By that logic every single possible template with variadic 
 parameters is wrapper around instantiation of type tuple. 
 std.typecons.Tuple does not store expression tuple inside so I 
 don't think it is legal to call it a "wrapper". Simply 
 pseudo-anonymous struct with pseudo-anonymous fields.


I'm afraid if you look at the implementation of 
std.typecons.Tuple, it does exactly what you say it doesn't do. 
The struct-like aspects (e.g. named access) are simulated using 
aliases.
Aug 17 2013
parent "Dicebot" <public dicebot.lv> writes:
On Saturday, 17 August 2013 at 14:19:06 UTC, John Colvin wrote:

 I'm afraid if you look at the implementation of 
 std.typecons.Tuple, it does exactly what you say it doesn't do. 
 The struct-like aspects (e.g. named access) are simulated using 
 aliases.


Checked once more and I stand corrected. At first glance at 
implementation I had impression that is exactly the other way 
around. That makes situation even more fun.
Aug 17 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/17/2013 02:37 PM, Dicebot wrote:

 1) collections of items, called tuples. They can contain pretty much
 anything you want, as long it's available at compile-time.
 They are ***not types***. If and only if a tuple contains only types,
 the tuple itself is a type. This is often referred to as a type-tuple.
 In current D, tuples of all varieties are created by variadic template
 parameters.*


 All true but last statement. They are not "created" anywhere, this is
 simply most convenient way to capture built-in tuple in a form usable by
 user code.


Actually, they are created like this:

Foo!(int,"hello",2)
     ^~~~~~~~~~~~~~~


std.typetuple.TypeTuple is the identity "function" on template argument 
lists.
Aug 17 2013
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Wyatt:


 I don't like the "t".



know if it's technically acceptable).

Bye,
bearophile
Aug 16 2013
parent "Meta" <jared771 gmail.com> writes:
On Friday, 16 August 2013 at 23:51:50 UTC, bearophile wrote:

 Wyatt:


 I don't like the "t".



 know if it's technically acceptable).

 Bye,
 bearophile


For reference:

http://forum.dlang.org/thread/evamvyfxasouvwzublxc forum.dlang.org
Aug 16 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 16, 2013 at 06:08:36PM +0200, bearophile wrote:

 John Colvin:
 

Possible solutions:


 
 My vote is for solution n.5:
 
 Add the built-in t{} syntax to denote all kind of tuples.


[...]

This can be part of the solution, but by itself is not good enough,
because the so-called "typetuple" and std.typecons.Tuple are NOT the
same thing. They are completely unrelated types, in fact incompatible
concepts, and we need some way to indicate that they aren't the same
thing. Otherwise they will continue to cause confusion.

The so-called "typetuple" (what dmd calls a "tuple") is a compile-time
construct that can contain types, aliases, compile-time values, etc.,
that only exist at compile-time. On the contrary, std.typecons.Tuple is
a runtime object that contains a sequence of values stored in memory (it
has nothing to do with what dmd calls a "tuple"). The two are NOT the
same thing.

I think a good start is to call them by different names. The word
"tuple" is just too overloaded right now, and using the same term to
refer to two incompatible things is just formula for endless confusion.
"Sequence" is OK, but risks confusion with std.range.sequence. Is there
a better word for it? Maybe an acronym -- CTS (compile-time sequence)?


T

-- 
Guns don't kill people. Bullets do.
Aug 16 2013
next sibling parent "QAston" <qaston gmail.com> writes:
On Friday, 16 August 2013 at 16:28:29 UTC, H. S. Teoh wrote:

 I think a good start is to call them by different names. The 
 word
 "tuple" is just too overloaded right now, and using the same 
 term to
 refer to two incompatible things is just formula for endless 
 confusion.
 "Sequence" is OK, but risks confusion with std.range.sequence. 
 Is there
 a better word for it? Maybe an acronym -- CTS (compile-time 
 sequence)?


 T


Typetuple allows random access to elements, so maybe array is 
better than sequence. Compile-Time annotation is very nice as it 
explicitly states the usage and capabilities of the construct. 
Also - the acronym is already known thanks to CT-FE.
Aug 16 2013
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/16/2013 09:27 AM, H. S. Teoh wrote:


 The so-called "typetuple" (what dmd calls a "tuple") is a compile-time
 construct that can contain types, aliases, compile-time values, etc.,
 that only exist at compile-time.


They are all symbols, right? And symbols live only at compile time.

...


 "Sequence" is OK, but risks confusion with std.range.sequence. Is there
 a better word for it? Maybe an acronym -- CTS (compile-time sequence)?


SymbolTuple it is! :)

Ali
Aug 16 2013
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 16, 2013 at 11:10:28AM -0700, Ali Çehreli wrote:

 On 08/16/2013 09:27 AM, H. S. Teoh wrote:
 

 The so-called "typetuple" (what dmd calls a "tuple") is a
 compile-time construct that can contain types, aliases, compile-time
 values, etc., that only exist at compile-time.


 
 They are all symbols, right? And symbols live only at compile time.
 
 ...
 

 "Sequence" is OK, but risks confusion with std.range.sequence. Is
 there a better word for it? Maybe an acronym -- CTS (compile-time
 sequence)?


 
 SymbolTuple it is! :)


[...]

+1, I like this!  I still don't like the use of "tuple", but I think
"symbol" makes it abundantly clear what these things are.

I vote for SymbolTuple.


T

-- 
Живёшь только однажды.
Aug 16 2013
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/16/2013 11:21 AM, H. S. Teoh wrote:


 On Fri, Aug 16, 2013 at 11:10:28AM -0700, Ali Çehreli wrote:

 On 08/16/2013 09:27 AM, H. S. Teoh wrote:


 The so-called "typetuple" (what dmd calls a "tuple") is a
 compile-time construct that can contain types, aliases, compile-time
 values, etc., that only exist at compile-time.


 They are all symbols, right? And symbols live only at compile time.

 ...


 "Sequence" is OK, but risks confusion with std.range.sequence. Is
 there a better word for it? Maybe an acronym -- CTS (compile-time
 sequence)?


 SymbolTuple it is! :)


 [...]

 +1, I like this!  I still don't like the use of "tuple",


Same here: tuple is confusing. :/

I also thought about SymbolList but then it doesn't go well with random 
accessing its elements.


 but I think
 "symbol" makes it abundantly clear what these things are.

 I vote for SymbolTuple.


Me too! :p

Ali
Aug 16 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 16 August 2013 at 18:10:29 UTC, Ali Çehreli wrote:

 On 08/16/2013 09:27 AM, H. S. Teoh wrote:


 The so-called "typetuple" (what dmd calls a "tuple") is a


 compile-time

 construct that can contain types, aliases, compile-time


 values, etc.,

 that only exist at compile-time.


 They are all symbols, right? And symbols live only at compile 
 time.


Not really. At least as far as my understanding goes, for 
example, integer literals are not symbols. Symbols usually 
uniquely identify something (and are possibly emitted to object 
files) and this is not the case for compile-time tuple elements. 
Symbols are most closely related to `alias` parameters (it does 
have inconsistencies of its own though).
Aug 16 2013
prev sibling parent captaindet <2krnk gmx.net> writes:
On 2013-08-16 13:10, Ali Çehreli wrote:

 On 08/16/2013 09:27 AM, H. S. Teoh wrote:

  > The so-called "typetuple" (what dmd calls a "tuple") is a compile-time
  > construct that can contain types, aliases, compile-time values, etc.,
  > that only exist at compile-time.

 They are all symbols, right? And symbols live only at compile time.

 ...

  > "Sequence" is OK, but risks confusion with std.range.sequence. Is there
  > a better word for it? Maybe an acronym -- CTS (compile-time sequence)?

 SymbolTuple it is! :)

 Ali


other posts made the point that it should not have "tuple" in the word at all.
so what about just "symbols"? i would be happy to see it as a fully explained
and supported language feature. then "symbols" could even be a key word in D
and used without "!". it seems that all proposed short syntaxes have issues
anyway, and i don't find symbols(int,"string",3,foo) too verbose.


/det
Aug 16 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 16 August 2013 at 16:28:29 UTC, H. S. Teoh wrote:

 This can be part of the solution, but by itself is not good 
 enough,
 because the so-called "typetuple" and std.typecons.


Key point is that having proper built-in syntax for 
type/expression tuples obsoletes the need in TypeTuple and it can 
be deprecated completely.
Aug 16 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, August 16, 2013 18:08:36 bearophile wrote:

 John Colvin:

 Possible solutions:


 My vote is for solution n.5:
 
 Add the built-in t{} syntax to denote all kind of tuples.


Since the built-in tuples / std.typetuple.TypeTuple and std.typecons.Tuple 
are fundamentally different, I don't see how you could possibly combine the two 
in a single syntax. You'd need different syntaxes for each one.

- Jonathan M Davis
Aug 16 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 16 August 2013 at 19:19:19 UTC, Jonathan M Davis wrote:

 Since the built-in tuples / std.typetuple.TypeTuple and 
 std.typecons.Tuple
 are fundamentally different, I don't see how you could possibly 
 combine the two
 in a single syntax. You'd need different syntaxes for each one.


The fact that std.typetuple.TypeTuple and built-in ones are 
different is most inconvenient thing in all this situation. They 
should be the same and TypeTuple removed as redundant.
Aug 16 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, August 16, 2013 21:23:26 Dicebot wrote:

 On Friday, 16 August 2013 at 19:19:19 UTC, Jonathan M Davis wrote:

 Since the built-in tuples / std.typetuple.TypeTuple and
 std.typecons.Tuple
 are fundamentally different, I don't see how you could possibly
 combine the two
 in a single syntax. You'd need different syntaxes for each one.


 
 The fact that std.typetuple.TypeTuple and built-in ones are
 different is most inconvenient thing in all this situation. They
 should be the same and TypeTuple removed as redundant.


But TypeTuple and the built-in ones _aren't_ different. TypeTuple is an alias 
for the built-in ones that's required because of the lack of syntax for 
declaring them on their own. TypeTuple could just have easily been called 
BuiltInTuple (and would probably have been better named as such, even though 
that name isn't exactly great). It's std.typecons.Tuple which is different.

Adding a syntax for TypeTuple, making TypeTuple redundant would be great, but 
Bearophile seems to be arguing that having some sort of tuple syntax would 
make it so that we don't need TypeTuple and Tuple, which is wrong, because 
they're different. If you're creating a new syntax in the language for one of 
them, you only get rid of the need for one of them in the library, not both. 
The idea of a "universal tuple" (like Bearophile seems to be looking for) 
makes no sense given the differences between the built-in tuples and Tuple.

- Jonathan M Davis
Aug 16 2013
parent "Dicebot" <public dicebot.lv> writes:
On Friday, 16 August 2013 at 19:35:56 UTC, Jonathan M Davis wrote:

 But TypeTuple and the built-in ones _aren't_ different. 
 TypeTuple is an alias
 for the built-in ones that's required because of the lack of 
 syntax for
 declaring them on their own.


That is intention but not implementation. There some cases where 
you can simply enumerate stuff via comma but can't use TypeTuple. 
There are cases where you can use TypeTuple but can't express the 
same thing with any built-in syntax. Recent discoveries on topic 
in bugzilla and digitalmars.learn have really frustrated me and I 
have considered myself somewhat experienced D user.


 Adding a syntax for TypeTuple, making TypeTuple redundant would 
 be great, but
 Bearophile seems to be arguing that having some sort of tuple 
 syntax would
 make it so that we don't need TypeTuple and Tuple..


Does he? I missed that from his comments. bearophile, is that 
true? :)

std.typecons.Tuple should be left untouched, of course, because 
it serves important goal - constructing a type (as module name 
suggests), something that can be used in ABI realm. It can make 
use of better integration with built-in tuples but it is a 
distinct topic.
Aug 16 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 16, 2013 at 03:35:40PM -0400, Jonathan M Davis wrote:
[...]

 Adding a syntax for TypeTuple, making TypeTuple redundant would be
 great, but Bearophile seems to be arguing that having some sort of
 tuple syntax would make it so that we don't need TypeTuple and Tuple,
 which is wrong, because they're different. If you're creating a new
 syntax in the language for one of them, you only get rid of the need
 for one of them in the library, not both.  The idea of a "universal
 tuple" (like Bearophile seems to be looking for) makes no sense given
 the differences between the built-in tuples and Tuple.


[...]

This is why I don't like the term "tuple". It's using a single word to
describe apples and oranges. It gives you the wrong idea that there's
some kind of underlying, unifying thing common to both, but there isn't!
We really need to start using different terms to refer to them,
otherwise the confusion will only continue.

If I could roll back time, I'd rename std.range.Tuple to
std.range.AnonStruct, because that's what it is -- an anonymous struct
that you put together on-the-spot by stringing a bunch of values
together. It has nothing to do with what DMD calls a "tuple" (except
that compile-time tuples, or CT-tuples, are used to implement it, but
that's an irrelevant implementational detail).

But I don't have a time machine, sad to say, and there's also precedent
for "tuple" in other languages in relation to what std.range.Tuple does,
so I'm expecting "tuple" will stick in this case.

Which leaves the compile-time thingies in need of a new, DIFFERENT name.
Ali's suggestion, SymbolTuple, is nice, but still has that dreaded
"tuple" in it, which still suggests some kind of conflation with
std.range.Tuple. I think we should avoid any name containing "tuple" for
these things. What about SymbolList? (maybe TypeList, but it's
misleading because it isn't restricted to types alone; plus I want to
avoid "sequence" in order to prevent the same confusion with
std.range.sequence).

Or maybe we should call them "tuplets" with a T (as in "quintuplet"). Or
"compile-time tuplets" (CT-tuplets), to distinguish them from Tuples.
The diminutive -t ending being a reference to the fact that they are
compile-time-only constructs, hence not "full-fledged Tuples".


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Aug 16 2013
parent reply "Dicebot" <public dicebot.lv> writes:
On Friday, 16 August 2013 at 20:22:49 UTC, H. S. Teoh wrote:

 ...


Term "tuple" comes from math and means "ordered set of elements". 
In that sense anonymous struct with unnamed fields _is_ a tuple 
and I thing std.typecons.Tuple is the place where naming is fine.

It is re-using the term for compile-time entity of the language 
that causes confusion. While it matches the mathematical 
definition of "tuple" too, its practical meaning for language is 
much more than that and naming should express it.
Aug 16 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, August 16, 2013 22:30:11 Dicebot wrote:

 On Friday, 16 August 2013 at 20:22:49 UTC, H. S. Teoh wrote:

 ...


 
 Term "tuple" comes from math and means "ordered set of elements".
 In that sense anonymous struct with unnamed fields _is_ a tuple
 and I thing std.typecons.Tuple is the place where naming is fine.
 
 It is re-using the term for compile-time entity of the language
 that causes confusion. While it matches the mathematical
 definition of "tuple" too, its practical meaning for language is
 much more than that and naming should express it.


In addition, the built-in tuples are not at all what most programmers think 
about when they think about tuples. Tuples are supposed to be nestable, 
whereas the built-in tuples are always flat. So, if anything, it's calling the 
built-in tuples tuples which is the problem. "Sequence" seems to be a semi-
popular suggestion for a better term whenever it comes up, but that poses its 
own set of difficulties.

- Jonathan M Davis
Aug 16 2013
prev sibling next sibling parent reply "Meta" <jared771 gmail.com> writes:
I was just thinking about the whole Tuple situation today. I 
think I might write up a quick, somewhat-related post.

As for TypeTuple, I agree that it is not a good name at all for 
what it does. It confused me endlessly when I first started 
learning D. There are still corner cases where it's not at all 
obvious what's going on. See Ali's thread in D.Learn about 
assigning a TypeTuple to an enum. Things got weird.

I think in Andrei's Modern C++ book there was a similar concept 
called Type Lists. That's still not a great name, as TypeTuple 
can contain more than just types. Maybe ExpressionList/ExprList?
Aug 16 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/16/2013 01:38 PM, Meta wrote:


 See Ali's thread in D.Learn about assigning a TypeTuple to an enum.


I think it was captaindet's "enum and tuples" thread that was 
specifically about enum and TypeTuple:

   http://forum.dlang.org/post/ku21fk$oqc$1 digitalmars.com

Ali
Aug 16 2013
parent reply "Meta" <jared771 gmail.com> writes:
On Friday, 16 August 2013 at 20:56:49 UTC, Ali Çehreli wrote:

 On 08/16/2013 01:38 PM, Meta wrote:


 See Ali's thread in D.Learn about assigning a TypeTuple to an 
 enum.


 I think it was captaindet's "enum and tuples" thread that was 
 specifically about enum and TypeTuple:

   http://forum.dlang.org/post/ku21fk$oqc$1 digitalmars.com

 Ali


Ah, sorry, my mistake. I thought you had that thread for some 
reason. I'm probably thinking of something else.
Aug 16 2013
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 08/16/2013 02:11 PM, Meta wrote:


 On Friday, 16 August 2013 at 20:56:49 UTC, Ali Çehreli wrote:



 I think it was captaindet's "enum and tuples" thread that was
 specifically about enum and TypeTuple:

   http://forum.dlang.org/post/ku21fk$oqc$1 digitalmars.com

 Ali


 Ah, sorry, my mistake. I thought you had that thread for some reason.


No, that's ok. That thread taught me a lot about TypeTuples. :)

Ali
Aug 16 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 16 August 2013 at 16:03:22 UTC, John Colvin wrote:

 Denis has been complaining about this for ages and I think it's 
 worth doing something about.

 Definitions:

 std.typecons.Tuple
 A bit like python's tuples. It's a heterogeneous collection of 
 runtime values with compile-time determined types.

 std.typetuple.TypeTuple
 A heterogeneous *compile-time* collection of types, expressions 
 and aliases.


 Problems:

 TypeTuple isn't just a typetuple, it's an everythingtuple. It's 
 a terrible name that is confusing to newcomers (and even to 
 people who've used D a lot but not delved in to the CT 
 capabilities so much).

 TypeTuple looks too much like Tuple. It's a totally different 
 concept but the names are too similar.


 Possible solutions:

 1) rename TypeTuple in-place to something better. This is not a 
 real option as it would break far too much code.

 2) Introduce a new tuple constructor with a new name, and 
 deprecate TypeTuple

 2a) A whole new module, leaving std.typetuple as effectively an 
 alias to the new module. Denis has a pull for this[1], which 
 also adds new tuple constructors specialised for expressions.


 I like Denis' pull request. It fixes the problem in a backwards 
 compatible manner. However - as Jonathan points out in the 
 comments - the naming is still a problem. GenericTuple, 
 ExpressionTuple etc. all sound like they could be related to 
 std.typecons.Tuple

 So, we need a new name:
 Sequence, ArgList or ParamList are possible suggestions.


 A possible complete path to getting this sorted, using Sequence 
 as an example:

 1) Create a new module like in Denis' PR, called std.sequence 
 and containing the template Sequence, equivalent to current 
 std.typetuple.TypeTuple

 1a) optional: include specific templates like TypeSequence and 
 ExpressionSequence.

 2) Leave std.typetuple as an alias to the new module, including 
 alias TypeTuple = Sequence; Deprecate it.

 3) std.traits.isTypeTuple becomes isTypeSequence and 
 isExpressionTuple becomes isExpressionSequence.   Deprecated 
 aliases from the old names are left for compatibility.

 4) Change phobos over to using std.sequence (note that this is 
 not required immediately, as there is 100% backwards 
 compatibility).

 The only remaining headache would be people getting confused by 
 dmd spewing out complaints about tuple(blah, blah, blah), but 
 that's a relatively minor concern.


 P.S. please note that deprecating is not breaking, per se. 
 Deprecations are just warnings by default. Also, although 
 having compatibility aliases floating around is annoying, it's 
 an unfortunate necessity if one wants to change things while 
 not breaking everyone's code. I think it's a model we're going 
 to have to get used to in order to be both flexible and 
 reliable.

 [1] https://github.com/D-Programming-Language/phobos/pull/780


How do you guys feel about ctList/CtList/CTList?
Aug 16 2013
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
http://wiki.dlang.org/The_D_Programming_Language/Seq
Aug 17 2013
parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 17 August 2013 at 15:50:51 UTC, Timon Gehr wrote:

 http://wiki.dlang.org/The_D_Programming_Language/Seq


I added a little bit on multiple return values.
Aug 17 2013