A Discussion of Tuple Syntax

[H. S. Teoh]

On Wed, Aug 21, 2013 at 03:43:45AM +0200, bearophile wrote:
> Andrei Alexandrescu:
> 
> >1. What do we need?
> 
> We can live fine without a syntax to manage tuples, so strictly
> speaking we need nothing (almost, I'd like to kill one currently
> accepted syntax, see below).
> 
> But when you write D in a high-level style, and you are used to
> other functional or scripting languages, in several cases you desire
> a more handy/compact syntax to manage tuples.
> 
> Tuples are simple data structure, so the operations you want to do
> with them are few and simple:
> - To define a tuple of various fields of different type, that is a
> tuple literal, to create a tuple;

This is adequately taken care of by std.typecons.Tuple, isn't it?


> - A way to read and write items of a tuple (unless it's read-only),
> D uses a nice syntax [i] as arrays indexing, but i can't be a
> run-time value.

You can't make 'i' a runtime value because D is a statically-typed
language. The compiler has to know at compile-time what type tup[i] is.
Otherwise it couldn't generate machine code for things like:

	void func(Tuple t, int i) {
		auto x = t[i];	// what's the type of x?
	}


> - With the Phobos tuple we are used to giving names to fields. It's
> handy, but it's not so necessary if you have a way to assign tuple
> items to variables, defined in-place. There are several places where
> pulling apart a tuple in that way is useful, here I use a basic
> syntax to be more clear:
> 
> Assignments:
> auto (a, b) = t1;

Currently you could do:

	Tuple!(...) t1;
	auto a = t1[0];
	auto b = t1[1];

Not as nice, certainly, but I wouldn't consider it a deal-breaker.


> In function signatures:
> auto mult = ((int x, int y)) => x * y;

Currently we have:

	auto mult = (Tuple!(int,int) t) => t[0] * t[1];

Not as pretty, but surely still readable and usable? Or am I missing
something?


> In foreach loops:
> 
> void main() {
>   import std.range, std.stdio;
>   auto a = [10, 20];
>   auto b = [100, 200];
> 
>   // Currently D supports this syntax:
>   foreach (x, y; zip(a, b))
>     writeln(x, " ", y);
> 
>   // But it's unreliable, now x is the index of the
>   // array instead of the first tuple fields, so I
>   // think this feature of D should be killed as
>   // soon as possible:
>   foreach (x, y; zip(a, b).array)
>     writeln(x, " ", y);
> }

Isn't this an auto-expanding tuple that Andrei didn't like?

Though granted, the current way of expressing it is not as nice:

	foreach (t; zip(a,b)) {
		writeln(t[0], " ", t[1]);
	}


[...]
> There are few more little pieces that are useful, like unpacking an
> array:
> 
> string s = "red blue";
> auto (col1, col2) = s.split;

What should happen if s is a runtime variable that may not have the same
number of words as the number of elements in the tuple on the left-hand
side? A runtime error?


[...]
> For an use case of the assignment from an array, let's say you have
> a text file containing two numbers in a line, that you want to read:
> 
> const (x, y) = filein.byLine.front.split.to!(int[]);
[...]

Again, what should happen if at runtime the lines have more or less
elements than the tuple on the left-hand side? A runtime error?

I didn't look in detail at your red-black tree example, or the Huffman
encoding example, but it would seem that currently, std.typecons.Tuple
more-or-less suffices for your needs, right? Except for some syntactic
unpleasantness, that is.

Or is there something that *can't* be expressed in an adequate way by
the current Tuple that I missed?

Also, I note that none of your examples need TypeTuples at all, so it
would appear that your use case do not necessitate the unification of
TypeTuple with Tuple. Though that would be nice conceptually, it does
introduce a lot of complications into the language and require
addressing some non-trivial issues which, taking a step back, perhaps we
don't *need* to address, because they are of little or no practical use?


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce