Tue, 31 Mar 2009 17:54:30 -0700, Andrei Alexandrescu wrote:
> Bill Baxter wrote:
>> On Wed, Apr 1, 2009 at 6:16 AM, Andrei Alexandrescu
>> <seewebsiteforem...@erdani.org> wrote:
>>> 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?
>>
>> I should say that by "in my ideal world" what I meant was "forgetting
>> about all the baggage that D already has for a moment and starting
>> from a more or less clean slate". Things like the useless comma
>> operator.
>>
>> But isn't a juxtaposition of two types a syntax error? So the above
>> would be a function type, not a juxtaposition of two types.
>>
>>> Is (A, B) an expression or a type? And so on.
>>
>> How does that differ from asking "Is A an expression or a type?"
>>
>> If A and B are types, then (A,B) is a type.
>>
>>>> (int,float) z = returns_tuple();
>>> Blech.
>>
>> Blech to that, but you like
>> Tuple!(int,float) z = returns_tuple();
>> correct?
>>
>>>> (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).
>>
>> Belch to that, but again, you're saying this is great
>> auto tup = Tuple!(2, 3.4);
>> correct?
>>
>> --bb
>
> Yah, sorry for the dismissive comments... what I meant was that the
> literal you suggested is so ambiguous grammatically, it's a
> non-improvement compared to just writing Tuple! there.
Comma expression is not ambiguous. It's a comma expression. Renaming
it into a tuple constructor expression does not add any ambiguity.
Parentheses here are only required to separate the comma expression from
an assignment expression which otherwise would become a part of comma
expression. Sure there are problems with making tuples first-class, but
this is certainly not one of them.
I'm putting together a blog post about a possible design of first-class
tuples in D. Hope it won't take too long.
