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.
For me the distinction is that I would only consider writing a
function that returns something like "Tuple!(int, float)" as a last
resort when no other design would work. I would sooner use two out
parameters.
Why? I use tuple returns all over.
But in Python or ML, no question. I'd happily write a function that
returns (2, 4.2) without giving it much thought. Now perhaps cogent
arguments like "blech" and "belch" can convince me that I should
embrace the Tuple!(int,float) and use it everywhere, just like I'd use
tuples in Python and ML, but so far I'm not convinced.
To me it seems to be in the same league as int[] vs std::vector<int>.
int[] -- great I'll happily use that everywhere. std::vector<int>
kind of a pain, use begrudgingly as needed.
Well I think a language can only have so many built-in types. We can't
go on forever.
Andrei
