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
