On 2010-10-07 04:20:23 -0400, Andrei Alexandrescu
<[email protected]> 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
[email protected]
http://michelf.com/
