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.
