A Discussion of Tuple Syntax

[Andrei Alexandrescu]

On 8/20/13 1:24 PM, Dicebot wrote:
>> That would be problematic to say the least. (There have been a few
>> discussions in this group; I've come to think auto expansion is fail.)
>
> :O it is awesome!

"Spawn of Satan" would be a tad more appropriate.

> Stuff like foo(myStructInstance.tupleof) is very
> powerful tool for generic interfaces.

One problem with automatic expansion is that now there's a whole new 
kind - a single expression that doesn't quite have one value and one 
type, but instead is an explosion of other expressions.

The problem now is how to contain these things - presumably one should 
associate a self-exploding tuple with a symbol:

auto pack = functionReturningTuple();

The symbol should not expand when, for example, assigned to another:

auto packCopy = pack;

However, the symbol _should_ expand "where it should", presumably in a 
function code:

auto m = min(pack, 0);

So this will invoke min with various numbers of arguments depending on 
what pack contains. Same with e.g.

writeln(pack);

Before one even realizes it, the matter of when to expand vs. when not 
to expand becomes a thing. That thing will have people confused (because 
now an expression isn't what it seems; it may be, in fact, several 
expressions at once). It will get explained in articles and books. There 
will be debates about choices of automatic unpacking vs. not in which 
reasonable people may disagree. People will get all confused about it. 
Generic code won't be able to tell much about what's going on because 
arity can't be guaranteed anymore.

Alternatively, we could do what Go does and prevent all packing 
altogether (if I understand what Go does correctly). That is, if a 
function returns a tuple you can't even keep that tuple together unless 
you use some handcrafted solution. In that case, before long there will 
be some "Pack" structure and some pack helper function, viz. the 
converse of .expand.

Clearly both packing and unpacking tuples are necessary. The question is 
what the default is. My argument here is that keeping one 
expression/symbol have one value is so deeply embedded in the semantics 
(and the ethos for that matter) of D, that it would be a major step 
backwards to retrofit it all to accommodate self-expanding tuples. Not 
speaking for other languages, I think it's great that in D

writeln(x);

is known to take an argument, whereas

writeln(x.expand);

takes zero or more arguments. It is the best compromise I can imagine 
that keeps the language sealed tight.

> Do you remember any keywords to
> look for to find those discussions? Ones I remember were mostly about
> auto-expansion _not_ happening in some reasonable places.

Ionno so I just summarized it.


Andrei