DIP19: Remove comma operator from D and provision better syntactic support for tuples

[Michel Fortin]

On 2012-09-25 15:08:25 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail at 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.fortin at michelf.ca
http://michelf.ca/