<div dir="ltr"><div class="gmail_extra"><div class="gmail_extra">Sorry I cannot reply to each thread comments quickly, so I discharge my opinions at once.</div><div class="gmail_extra"><br></div><div class="gmail_extra">----<br>
</div><div class="gmail_extra">D's built-in tuple can contain following entities:<br></div><div class="gmail_extra"><div class="gmail_extra"> - Type</div><div class="gmail_extra">    int, long, array types, AA types, user-defined types, etc</div>
<div class="gmail_extra"> - Expressions</div><div class="gmail_extra">    interger, string literal, etc</div><div class="gmail_extra"> - Symbol</div><div class="gmail_extra">    user-defined types, templates, template instances, etc</div>
<div><br></div></div><div class="gmail_extra">Note that: an user-defined type would be treated as both Type and Symbol.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">template Test() {}</div>
<div class="gmail_extra">alias X = std.typetuple.TypeTuple!(</div><div class="gmail_extra">    int, long, char[], int[int], const Object,  // Types</div><div class="gmail_extra">    1, "str", [1,2,3],  // Expressions (literal values)</div>
<div class="gmail_extra">    object.Object, Test, Test!(),   // Symbols</div><div class="gmail_extra">);</div><div><br></div></div><div class="gmail_extra">If all of the elements in a built-in tuple are Type, today it is normally called "Type Tuple".</div>
<div class="gmail_extra">If all of the elements in a built-in tuple are Expressions, today it is normally called "Expression Tuple".</div><div class="gmail_extra"><br></div><div class="gmail_extra">Note that: today we cannot create a built-in tuple without using TemplateTupleParameter.</div>
<div class="gmail_extra">TemplateTupleParameter cannot take expressions non-literal expressions, therefore</div><div class="gmail_extra">most of current built-in tuples would contains only literal values as the Expressions.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">----</div><div class="gmail_extra">std.typecons.Tuple is an artifact of built-in tuple + alias this.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">
<div class="gmail_extra">struct Tuple(T...) {</div><div class="gmail_extra">    T expand;   // 'expand' is a built-in tuple of</div><div class="gmail_extra">                // the implicitly defined fields that</div>
<div class="gmail_extra">                // typed T[0], T[1], ... T[$-1].</div><div class="gmail_extra">                // In spec, this is called "TupleDeclaration".</div><div class="gmail_extra">    alias expand this;  // forward indexing/slicing operators to</div>
<div class="gmail_extra">                        // the TupleDeclaration 'expand'</div><div class="gmail_extra">}</div><div class="gmail_extra">Tuple!(int, string) t;</div><div class="gmail_extra">t[];        // t.expand[]</div>
<div class="gmail_extra">t[0..$];    // t.expand[0..$]</div><div class="gmail_extra">t[1];       // t.expand[1]</div><div><br></div></div><div class="gmail_extra">So, std.typecons.Tuple _is not special_. You can define another Tuple struct in the same way.</div>
<div class="gmail_extra">We should not define new syntax for the library utility std.typecons.Tuple.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If you want to return multiple values from a function, you must always wrap them by std.typecons.Tuple, or other used-defined types. You cannot directly return built-in tuple from a function.</div>
<div class="gmail_extra">(Built-in tuple return is mostly equivalent with multiple-value-return issue. However it would be mostly impossible that defining calling conversion scheme for that in portable)</div><div class="gmail_extra">
<br></div><div class="gmail_extra">----</div><div class="gmail_extra">The combination of built-in tuple and alias this would be one of the case of built-in tuple of non-literal Expressions.</div><div class="gmail_extra">For example, `t.expand[1]` is equivalent with the dot expression `t.__field_1` which cannot be taken by TemplateTupleParameter.</div>
<div class="gmail_extra">Therefore, `t.expand` would be the built-in tuple of the two dot expressions `t.__field_0` and `t.__field_1`.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Therefore, calling built-in tuple "Alias Tuple" would not be correct so built-in tuple can contain expressions that cannot be aliased.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">----</div><div class="gmail_extra">My opinions agains various syntax proposals:</div><div class="gmail_extra"><br></div><div class="gmail_extra">#(1, "str")</div>
<div class="gmail_extra">--> The character '#' is already used for the start of "Special Token Sequences"</div><div class="gmail_extra"><a href="http://dlang.org/lex.html#Special">http://dlang.org/lex.html#Special</a> Token Sequence</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">It is recognized in lexing phase, so adding semantic meaning to the '#' character would be a contradict of D's principle.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Quote from <a href="http://dlang.org/lex.html">http://dlang.org/lex.html</a></div><div class="gmail_extra">"The lexical analysis is independent of the syntax parsing and the semantic analysis."</div>
<div><br></div><div>Kenji Hara</div></div></div>