Tuple literal syntax

[Michel Fortin]

On 2010-10-07 04:20:23 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Sorry for being Debbie Downer in this thread, but I'm not seeing a lot 
> of progress here. This is nothing but a syntax cutesy that helps 
> Tuple!(A, B) and tuple(a, b) and leaves all other issues related to 
> tuples unresolved (I'm actually afraid that it exacerbates them).
> 
> One good thing about Tuple is that it allows names of fields, so 
> functions can return tuples with conveniently named fields, e.g. 
> Tuple!(bool, "found", size_t, "position") etc. without having to define 
> little structs everywhere and fostering simple, clear code on the 
> caller side.

I've always found tuples with named arguments awkward. I mean, a tuple 
is a list of


> Also, obviously, empty tuples and tuples with one element are 
> self-explanatory (Tuple!() and Tuple!(int) for types, tuple() and 
> tuple(4) for values).

And then you have TypeTuple!(...) for tuples of types or 
statically-known values. The basic problem is that all these different 
syntaxes define slight variations of the same core tuple concept.

Giving a true syntax for tuples makes things *simpler* by reducing 
these variations. For instance, a TypeTuple!(int, int) isn't the same 
thing as Tuple!(int, int). Why is it so? Because of an implementation 
detail: one defines the core language tuple and the other defines a 
wrapper struct around the core tuple that implements what's basically 
missing in the core tuple implementation (returning from a function).

With Walter changes I expect you'll be able to call a function this way 
(simply because this is actually what happens when you use a real tuple 
in D):

	auto a = (1, 2);
	func(a); // same as func(a[0], a[1]);

Or you could have some kind of filter function that takes arbitrary 
arguments and transform them somehow before passing them to another 
function. For instance:

	auto square(T...)(T tuple) {
		foreach (ref element; tuple)
			element ^= 2;
		return tuple;
	}

	writefln("%d %d %d %d %d", square(1,2,3,4,5)); // prints "1 4 9 16 25"

I'm not inventing anything. This is exactly how the core language 
tuples work today in D. It's already possible to have core language 
tuples in variables (try creating a variable of type TypeTuple!(int, 
int), it works!). The only two things Walter is proposing to implement 
is tuple literals and tuple returns for functions.

And, if I'm guessing right, this syntax will also work:

	int a;
	float b;
	(a, b) = func(); // func returns a (int, float) which is directly
	                 // stored in the right variables

This has been proven very useful in languages that supports it; heck, 
even C++ has this feature with boost::tie. I assume it'll work because, 
well, it already works if the tuple isn't the return value of a 
function call:

	TypeTuple!(a, b) = TypeTuple!(1, 2);
	TypeTuple!(a, b) = tuple(1, 2).fields;


> Up until recently the syntax t[i] didn't work for tuples, forcing 
> t.field[i]. This marginally improves usage of tuples. There are still 
> other issues left due to compiler bugs; for example slicing t[a .. b] 
> is supposed to work but it doesn't. But my question is, do we need more 
> notation, more special cases, more ambiguities, more solution to 
> ambiguities, more corner cases (there's already a request for handling 
> void in a particular way)...? And for what? Quite literally because we 
> refuse to call a tuple a tuple? I'm not seeing much gain here. 
> Syntactic sugar is good in moderate quantities, but in Perlis' words 
> this is bound to cause cancer of the semicolon.

I find it hard to see how obsoleting one of the two tuple concepts (the 
one in Phobos) and keeping only the core language tuple will introduce 
more bugs. The tuple concept is already at the core of the language, 
and it is quite needed there too for metaprogramming an other stuff. We 
can't remove it, so let's improve it instead of layering a wrapper over 
it, giving it same name, and making things more confusing for everyone.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/