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

Timon Gehr timon.gehr at gmx.ch
Tue Sep 25 15:57:06 PDT 2012


On 09/25/2012 09:29 PM, kenji hara wrote:
> 2012/9/26 Jonathan M Davis <jmdavisProg at gmx.com>:
>> On Tuesday, September 25, 2012 13:45:50 Michel Fortin wrote:
>>> On 2012-09-25 16:38:31 +0000, "Jonathan M Davis" <jmdavisProg at gmx.com> said:
>>>> On Tuesday, September 25, 2012 12:28:15 Michel Fortin wrote:
>>>>> Although to make things less confusing, I think the built-in language
>>>>> tuple should give up its name. It could become a "sequence". Renaming
>>>>> the built-in one would certainly be less trouble, as code doesn't refer
>>>>> to it by its name, and you can pick a name that fits better with its
>>>>> auto-expanding behaviour.
>>>>
>>>> Not referred to by its name? It's refereed to as TypeTuple all over the
>>>> place. It's arguably a bad name, but it would break a _lot_ of code to
>>>> change it now.
>>> TypeTuple is only a construct allowing you to create a built-in
>>> language tuple, one that does not necessarily match the definition of a
>>> TypeTuple. The language spec defines a Tuples, TypeTuples, and
>>> ExpressionTuples with these words (ironically, using the word
>>> "sequence" twice):
>>>
>>> """
>>> If the last template parameter in the TemplateParameterList is declared
>>> as a TemplateTupleParameter, it is a match with any trailing template
>>> arguments. The sequence of arguments form a Tuple. A Tuple is not a
>>> type, an expression, or a symbol. It is a sequence of any mix of types,
>>> expressions or symbols.
>>>
>>> A Tuple whose elements consist entirely of types is called a TypeTuple.
>>> A Tuple whose elements consist entirely of expressions is called an
>>> ExpressionTuple.
>>> """
>>> Source: http://dlang.org/template.html
>>
>> I wasn't aware of that being in the language definition, but it doesn't change
>> the fact that they're used and referred to in code as TypeTuple, and renaming
>> that would break a lot of code. And it _is_ used for the built-in tuple type,
>> regardless of whether the spec considers the terms type tuple and expression
>> tuple to refer to distinct entities. Rename the stuff in the spec to whatever
>> you like, but the library uses the term TypeTuple, so it _is_ used in code.
>>
>> - Jonathan M Davis
>
> I like current design - open (built-in, automatically flattened, and
> *unpacked*) tuple, and closed (library, be structured, and *packed*)
> tuple.
>
> 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

+1.

>      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.
>
> Kenji Hara
>

I don't consider TypeSeq and ExpSeq crucial. They do not do more
checking than using the sequence in type or expression context triggers
automatically, but YMMV.




More information about the Digitalmars-d mailing list