On Tuesday, 20 August 2013 at 21:25:11 UTC, Andrei Alexandrescu
wrote:
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.
+1
I can stand explicit expansion though, like Go's variadic
argument ellipses syntax:
http://golang.org/doc/effective_go.html#append
OT: I'm not really a fan of D's variadic function syntax. I'd
prefer it to be explicit:
int sum(int[] ar ...) {
}
int[3] foo = [4, 5, 6];
sum(foo...);
sum(3, 4, foo...); // on my wish list...
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.
snip...
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.
+1
I've been itching for multiple returns in D for a long time, and
this seems like a nice way to add it in. I think I'd prefer to
use tuple syntax instead though, just so there's less magic:
(int, int) doStuff() {
return (1, 2);
}
// syntax error
auto a, b = doStuff();
// ok
auto (a, b) = doStuff();
Clearly both packing and unpacking tuples are necessary.
snip...
Andrei
OT: is the only thing stopping us from using the nice (x,y)
syntax for tuples the comma operator? If so, can we take that
mis-feature behind the woodshed and shoot it? I sincerely hope
nobody is relying on it...
