Tuples citizenship

[Dmitry Olshansky]

On 02.03.2012 6:06, bearophile wrote:
> Jonathan M Davis:
>
>> Yes, but chaining functions is the issue. It doesn't work well with tuples
>> unless the function you're passing the result to wants the tuple. If all it
>> wants is one piece of the tuple, then that doesn't work well at all.

just stick in .expand ?

void f(int x, int y){ }

void main()
{
	Tuple!(int, int) a;
	f(a.expand);
}


BTW it's nowhere to be found here
http://dlang.org/phobos/std_typecons.html


You're
>> forced to assign the tuple to something else and then call then function
>> rather than chain calls.
>
> In the years I have used a mountain of tuples in Python, but I barely perceive that problem, so I think it's not so bad.
>
>
>> int exp;
>> auto result = frexp(value, exp);
>>
>> vs
>>
>> auto tup = frexp(value);
>> result = tup[0];
>> exp = tup[1];
>
> I have assumed to use a sane tuple unpacking syntax. So the second part of your comparison is:
>
> immutable (result, exp) = frexp(value);
>
> That is better than your version with the out argument, safer, looks better, and you are even able to make both results constant.
>

+1

>
>> Getting tuple return values is annoying. Yes, it can be useful, but most stuff
>> doesn't operate on tuples. It operates on the pieces of tuples. So, you have
>> to constantly break them up. So, using out results in much nicer code.
>
> I think that the tuple unpacking syntax is able to avoid part of your problems.

s/part/most
I'd say that results clearly belond to the left side of x = fun(...) 
expression, and tuples + unpack syntax are the way to make it consistent.
With all sugar going on around Tuples, e.g. .tupleof, unpacking, I can't 
help but wonder why are they not built-ins. At least they should go to 
object.d/druntime like AA do.

-- 
Dmitry Olshansky