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
