Declaring Ref Variables Inside Function Calls

[Sergey Gromov]

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
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>> Bill Baxter wrote:
>>>> On Wed, Apr 1, 2009 at 5:03 AM, Sergey Gromov <snake.scaly at 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
>>>>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>>>>> Jarrett Billingsley wrote:
>>>>>>>>> 2009/3/30 dsimcha <dsimcha at 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.