On 2012-09-25 15:08:25 +0000, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
On 9/25/12 10:05 AM, deadalnix wrote:
OK, my bad. It means that tuple(...) behave differently than T...
defined tuples.
And both behave differently than Caml or Haskell's tuples.
isn't the time for some unification ? Preferably on how tuples work in
other languages, except if limitations can be shown and better proposal
are made (and not include that in D2.xxx).
I'm not sure actually. The way I look at it, built-in tuples are quite
low-level (types can't be spelled, automatic expansion and flattening,
undecided first-class semantics) and should seldom be dealt with
directly. The best use of built-in tuples is in the implementation of
truly well-behaved, composable tuples.
The built-in tuple is also quite useful when defining templates.
In essence, we have two kinds of tuples: the built-in language tuple is
the "unpacked" tuple while Phobos hosts the "packed" one. They each
have their own use case and they can coexist peacefully. But the
language itself needs to standardize on one or the other. Take this
example (which is currently illegal because you can't return a built-in
language tuple):
T getThings(T...)(T t)
{
return t;
}
In this situation, there is no question that the language tuple needs
to work as an expanded tuple inside the parameter list of getTuple.
But now, what is the return type of makeTuple(1,2)? Obviously it's
(int, int), but is (int, int) the same thing as T? Or is it a packed
version of T? Well, it can't be a packed version of T because T is
already the unpacked type. I mean that for a function that simply
return its argument this should work:
T t1;
T t2 = getThings!(T)(t1);
If the language made T… a packed tuple instead, then we could use the
packed tuple everywhere and unpack it where necessary, and something
like this could be used to make a packed tuple:
T getThings(T...)(T.expand t)
{
return T(t);
}
T t1;
T t2 = getThings!(T)(t1.expand);
But we can't have it both ways, and the above would be a very drastic
change to the language.
I'm of the opinion that if we want to add tuple returns to the language
(which I'd certainly like), it'll have to be the same kind of tuple we
currently have built-in in the language: the auto-expanding kind.
As we all know, this doesn't preclude anyone from building packed
library tuples:
Tuple!(T) getThings(T...)(T t)
{
return tuple(t);
}
Although to make things less confusing, I think the built-in language
tuple should give up its name. It could become a "sequence". Renaming
the built-in one would certainly be less trouble, as code doesn't refer
to it by its name, and you can pick a name that fits better with its
auto-expanding behaviour.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca/
