Declaring Ref Variables Inside Function Calls

[Bill Baxter]

On Wed, Apr 1, 2009 at 9:55 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.
>>
>> 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.

It could just be paranoia, but I prefer to avoid dependency on a
library type if it is possible.  If I use a library type as a part of
my code's public interface I'm saying that the functionality provided
by that library is so important that I think all users of my library
should use it also.

But this is the one negative reaction to Tuple!() that I could
probably be convinced to overcome.  For instance if it becomes clear
that everyone will be able to use Phobos and love and adore it, then I
think that issue goes away for me.  (But not the ugly syntax issue).
But I'm not quite there yet believing that, because y'know Phobos
hasn't historically been so good at getting everyone to adore it.

>> 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.

Ok, then we'll introduce balanced budget amendment for types to ensure
this doesn't happen.  For every new type added one must be removed.
We're going to vote complex types off the island, right?   Maybe we
could get rid of associative arrays as a built-in too.

--bb