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

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.

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

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  

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?

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

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

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

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.

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