DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Timon Gehr]

On 09/25/2012 11:01 PM, Andrei Alexandrescu wrote:
> On 9/25/12 4:14 PM, Jonathan M Davis wrote:
>> On Wednesday, September 26, 2012 04:29:13 kenji hara wrote:
>>> But, the two are often confused, by the word "tuple". It has
>>> introduced badly confusion in many discussions.
>>> To make matters worse, it had often invoked incorrect suggestion that
>>> merging the two into one.
>>>
>>> My suggestion is very simple.
>>> 1. Change all words "built-in tuple" in the documentation to "built-in
>>> sequence". Then, in the D language world, we can have clarify name for
>>> the built-in one.
>>> 2. Introduce new templates, Seq, TypeSeq, and ExpSeq.
>>>
>>> template Seq(T...) { alias T Seq; } // identical with
>>> std.typetuple.TypeTuple
>>> template TypeSeq(T...) if (allSatisfy!(isType, T)) { alias T TypeSeq; }
>>> template ExpSeq(T...) if (allSatisfy!(isExpression, T)) { alias T
>>> ExpSeq; }
>>>
>>> If you really want to a sequence with heterogeneous elements, use
>>> Seq template. Otherwise use TypeSeq or ExpSeq based on your purpose.
>>
>> In principle, renaming TypeTuple makes sense given it's bad name
>> (though I
>> really don't seem much point in separating expression tuples and type
>> tuples),
>> but it would break a _lot_ of code. And both Walter and Andrei are
>> increasingly against making any breaking changes.
>>
>> - Jonathan M Davis
>
> TypeTuple does a lot of harm. I'd be glad to rename it GenericTuple and
> leave TypeTuple as a slowly rotting alias.
>
> Andrei

I'd never use GenericTuple, because already after four usages it would
have been cheaper to just define Seq inline.

GenericTupleGenericTupleGenericTupleGenericTuple
template Seq(T...){ alias T Seq; }SeqSeqSeqSeq

What is the rationale for calling this construct a tuple anyway?
Programming language tuples usually impose more structure on the
data than just ordering.