Tuples

[Diggory]

On Monday, 27 May 2013 at 01:36:58 UTC, Jonathan M Davis wrote:
> On Monday, May 27, 2013 11:21:08 Manu wrote:
>> I have certainly been confused by the term 'tuple' used in D 
>> countless
>> times.
>> It seems to exist in a variety of different contexts, and 
>> every time I
>> think I understood it, I realise I'm probably wrong some time 
>> later.
>> There seems to be poor/no documentation 
>> comparing/distinguishing various D
>> tuples, also, there seems to be no real explicit syntax, which 
>> makes it
>> hard to recognise.
>> I can kinda handle a Tuple template, and then there are these 
>> type tuples,
>> and then expression tuples? What is the relationship between 
>> these? Are
>> they compatible? How do I distinguish them?
>
> You basically just have to worry about Tuple and TypeTuple. 
> Tuple is of course
> very easy to understand. TypeTuple is then just an alias for 
> the built-in
> tuples, which can hold basically anything. They're what 
> template parameter
> lists, function parameter lists, template argument lists, and 
> function
> argument lists are made of. And you can use them handily in 
> other places (such
> as foreach) by using TypeTuple explicitly. I believe that an 
> expression tuple
> is simply a TypeTuple which holds only expressions. In 
> practice, I think that
> the differences are fairly simple, but they take quite a bit to 
> wrap your head
> around - primarily due to the terminology used rather than the 
> actual concept.
>
>> Someone that understand what they're talking about should take 
>> some time to
>> write a comprehensive article on the matter :)
>
> I guess that I'll have to look at doing that after I finish the 
> article that
> I'm writing on ranges (that I really need to finish...).
>
>> Some of the things I have read seem to presume that I already 
>> know what
>> it's talking about, and as a result, lead to dismissing or 
>> misunderstanding
>> the article.
>
> I generally know what's going on with D, but there were talks 
> at dconf that
> taught be stuff about D that I'd either forgotten or never 
> known (like some of
> what was going on with moves in Ali's talk). D is nowhere near 
> as bad C++ with
> regards to how complicated it is, but it's still quite 
> complicated.
>
>> I think the practical take-away from my experience is that it 
>> ends up as
>> one of those 'too hard' concepts, that I develop a tendency to 
>> actively
>> avoid dealing with because it's confused me a number of times.
>> I typically just start typing stuff and hope it works. And if 
>> it doesn't I
>> fiddle with it until it eventually does (or I give up), and I 
>> never
>> *really* understand why.
>> I'll bet I'm not the only one...
>
> It's well worth understanding TypeTuple well enough to use it 
> with foreach, as
> it's a great way to generate unit tests, particularly when 
> you're dealing with
> templated functions. Phobos does that quite a lot, particularly 
> with strings.
> Take splitLines unit test for example
>
>     foreach (S; TypeTuple!(char[], wchar[], dchar[], string, 
> wstring,
> dstring))
>     {
>         auto s =
> to!S("\rpeter\n\rpaul\r\njerry\u2028ice\u2029cream\n\nsunday\n");
>
>         auto lines = splitLines(s);
>         assert(lines.length == 9);
>         assert(lines[0] == "");
>         assert(lines[1] == "peter");
>         assert(lines[2] == "");
>         assert(lines[3] == "paul");
>         assert(lines[4] == "jerry");
>         assert(lines[5] == "ice");
>         assert(lines[6] == "cream");
>         assert(lines[7] == "");
>         assert(lines[8] == "sunday");
>
>         lines = splitLines(s, KeepTerminator.yes);
>         assert(lines.length == 9);
>         assert(lines[0] == "\r");
>         assert(lines[1] == "peter\n");
>         assert(lines[2] == "\r");
>         assert(lines[3] == "paul\r\n");
>         assert(lines[4] == "jerry\u2028");
>         assert(lines[5] == "ice\u2029");
>         assert(lines[6] == "cream\n");
>         assert(lines[7] == "\n");
>         assert(lines[8] == "sunday\n");
>
>         s.popBack(); // Lop-off trailing \n
>         lines = splitLines(s);
>         assert(lines.length == 9);
>         assert(lines[8] == "sunday");
>
>         lines = splitLines(s, KeepTerminator.yes);
>         assert(lines.length == 9);
>         assert(lines[8] == "sunday");
>     }
>
> You get to unit test with 6 different types while only writing 
> the code once.
> That can be _extremely_ useful.
>
> - Jonathan M Davis

IMO we should have the following:

Tuple - Current Tuple implementation, equivalent to C++ tuple 
with the extra "naming" feature. Can be instantiated and passed 
around.

StaticTuple - Current TypeTuple implementation, equivalent to 
type of "..." parameter in template arguments. Should not be 
instantiable.

TypeTuple - A StaticTyple where all parts have been statically 
checked to be types. It should be easy to instantiate an actual 
Tuple using a TypeTuple. Note that the template system allows 
them to be the same type, ie. a StaticTuple!(int, float) == 
TypeTuple!(int, float) while a TypeTuple!("Hello") will fail to 
compile.

ExpressionTuple - A StaticTuple where all parts have been 
statically checked to be expressions.

It would be much easier to understand and it fills a big gap in 
the language - there's no guarantee than any methods such as 
"staticIndexOf" will work on the current "TypeTuple" if that 
tuple contains non-types. With the new system methods which can 
work on all types of static tuple can be moved to the 
"StaticTuple", while methods specific to a particular type of 
StaticTuple can be in the correct place.

It also shouldn't break any code since the only addition to 
TypeTuple is a check to make sure that the undocumented behaviour 
of using it with non-types is disallowed, and in the case that 
this undocumented feature is used the code can simply switch to 
StaticTuple and be done.

Another thing I'm not clear on is how "alias" template parameters 
interact with variadic parameters. Is it possible for a variadic 
parameter to be an alias? What happens if "alias T..." is used? 
(*goes off to check*)