On Sat, 10 Mar 2012 09:58:30 -0600, bearophile <bearophileh...@lycos.com> wrote:
Robert Jacques:
The proposed unpacking syntax, IIRC, was:
(double a, int b) = fun();
which lowered to:
auto __tup = fun();
double x = __tup[0]; // __tup[0] has a type that is implicitly convertible to
double
int y = __tup[1]; // ditto
Why not instead lower to:
auto __tup = fun();
double x = __tup.tupleof[0];
int y = __tup.tupleof[1];
The advange of lowering it to:
auto __tup = fun();
double x = __tup[0];
Is that it works with this too:
int[2] foo() { return [10,20; }
auto (x,y) = foo();
This case is quite common.
Bye,
bearophile
And should not tupleof work with int[2] as well? Ever since int[2] switched to
being by value, as opposed to by reference it has behaved, under the hood, just
like a struct with 2 int fields. For that manner, a lot of generic programming
would get simpler if tupleof worked with the built-in D types.
(Of course we could just hack it via static if statements)
