Tuples citizenship

deadalnix deadalnix at gmail.com
Fri Mar 2 01:34:32 PST 2012


Le 02/03/2012 02:10, Jonathan M Davis a écrit :
> On Thursday, March 01, 2012 18:57:15 bearophile wrote:
>> Jonathan M Davis:
>>> They also often do poorly when you
>>> need to use the functional programming,
>>
>> As you know functional languages use tuples all the time.
>
> 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. You're
> forced to assign the tuple to something else and then call then function
> rather than chain calls. That's one of the reasons that you constantly end up
> using stuff like let expressions and pattern matching in functional languages.
> You don't _want_ a tuple. Dealing with a tuple is annoying. It's just that
> it's often the best tool that you have to pass disparate stuff around, so
> that's what you use.
>
>>> And if you're not looking to assign the parts of a tuple to
>>> existing variables, then they're not quite as bad as when you are, since
>>> you don't necessarily have to then assign the pieces to other variables.
>> There are parts of your post that I don't fully understand.
>
> It is often really annoying to have to deal with tuple return values, because
> you have to worry about unpacking the result. I don't want to use a tuple in
> the caller. Tuples are generally for grouping unrelated data that you don't
> necessarily want to keep togother (since if you did, you'd generally use a
> struct). I want the result to actually be assigned to variables. That is
> definitely cleaner with out than with tuples.
>
> int exp;
> auto result = frexp(value, exp);
>
> vs
>
> auto tup = frexp(value);
> result = tup[0];
> exp = tup[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.
>
> It always feels like I'm fighting the code when I have to deal with tuple
> return values.
>
> - Jonathan M Davis

Do you rally think that shorter is always better ? I don't think so. I 
think better is what the piece of code do pretty much what you expect it 
to do. And most of the time, I want to pass argument to a function not 
return value throw arguments. At the callee place, version look just 
like any other function call, but exp isn't a parameter, it is actually 
a returned value. You cannot know that reading the code, you need to 
know about frexp declaration - thus you scroll more source 
code/documentation or rely on your memory that will sometime fail. To 
emphasis that, just imagine the same scenario with a function that isn't 
from the standard lib.

This practice will confuse a newcomer that don't know the stdlib well, 
and, used in thrid party code, will confuse anyone expect the one that 
write that piece of code.


More information about the Digitalmars-d mailing list