Bill Baxter wrote:
On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov <snake.sc...@gmail.com> wrote:
Tue, 31 Mar 2009 12:18:21 -0700, Andrei Alexandrescu wrote:
Jarrett Billingsley wrote:
On Tue, Mar 31, 2009 at 1:32 PM, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Jarrett Billingsley wrote:
2009/3/30 dsimcha <dsim...@yahoo.com>:
// How it works now:
uint foo;
string bar;
unpack(foo, bar) = someFunction();
// vs. how I want it to work:
unpack(auto foo, auto bar) = someFunction();
Cute, but uh, I'd much rather see tuples just be returnable.
They are.
template Tuple(T...)
{
alias T Tuple;
}
Tuple!(int, float) foo()
{
return Tuple!(3, 4.5);
}
foo.d(10): Error: functions cannot return a tuple
Unless you're using some prerelease compiler, they are not.
import std.typecons;
Tuple!(int, float) foo()
{
return tuple(2, 4.5);
}
The addition of the alias this feature and of constructor templates
makes std.typecons.Tuple even better.
Andrei
Unfair---std.typecons.Tuple is actually a struct!
Well, basically struct is a run-time tuple, anyway.
I think that all the buzz around "actual tuple support" boils down to
requests for syntax sugar for construction and decomposition of
anonymous structs. While typecons.Tuple is sorta OK for construction,
things are still pretty ugly on the "decomposition" end.
Right. In my ideal world I could use tuples like this:
(int,float) a;
That sucks. Is int(int, float) a function type or a juxtaposition of two
types? Is (A, B) an expression or a type? And so on.
a = returns_tuple();
a[0] = 2;
a[1] = 3.4;
That works in my tree already due to alias this.
(int,float) z = returns_tuple();
Blech.
(int x, float y) = returns_tuple();
I'd like that too, but what we should have is make any definition an
expression.
auto tup = (2, 3.4);
Belch (sic).
takes_int_and_float(unpack!(tup));
Meh.
I think experience with tuples in Python and ML (and probably
elsewhere -- heck even D) shows that tuples are incredibly useful. So
useful that they deserve better syntax than Tuple!(...).
Ehm.
Andrei
