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 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 =?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 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 next 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 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 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 "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
prev sibling next sibling parent "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
prev sibling 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 "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
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

 construct that can contain types, aliases, compile-time

 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 next 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 next sibling parent "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".

 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:"

The DIP itself, though, looks pretty good. -Wyatt
Aug 16 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, August 16, 2013 18:08:36 bearophile wrote:
 John Colvin:
 Possible solutions:

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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent "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
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 =?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 "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 "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
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 next sibling parent "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:"


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
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Wyatt:

 I don't like the "t".

In another thread Meta has suggested a #() syntax. (But I don't know if it's technically acceptable). Bye, bearophile
Aug 16 2013
prev sibling next sibling parent "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) { // assuming we adopt #(...) syntax: alias makeType = #(x,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
prev sibling next sibling parent "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
prev sibling next sibling 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".

In another thread Meta has suggested a #() syntax. (But I don'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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
http://wiki.dlang.org/The_D_Programming_Language/Seq
Aug 17 2013
prev sibling 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