Tuples citizenship

[Jonathan M Davis]

On Friday, March 02, 2012 00:05:22 deadalnix wrote:
> Le 01/03/2012 23:33, Jonathan M Davis a écrit :
> > On Thursday, March 01, 2012 17:08:44 bearophile wrote:
> >> I think std.typecons.Tuples merit to be a little more citizens in D and
> >> Phobos. I think reducing the usage of "out" argument, and replacing them
> >> with a tuple result, will avoid mistakes and make the code look better.
> >> In
> >> std.math there are functions that maybe are better to use
> >> std.typecons.Tuple:
> >> 
> >> pure nothrow @trusted real frexp(real value, out int exp);
> >> ==>
> >> pure nothrow @trusted Tuple!(real, int) frexp(real value);
> > 
> > [snip]
> > 
> > Having good tuple support is great, but out parameters are great too. I'm
> > sure that there are plenty of cases where using out parameters is
> > actually far cleaner than using tuples, since you don't have multiple
> > return values to deal with. So, better enabling tuples is great, but I
> > don't think that we're necessarily moving in a good direction if we're
> > trying to eliminate out parameters in favor of tuples.
> > 
> > - Jonathan M Davis
> 
> I don't think out parameter is a great idea. This is rather confusing.
> 
> I tend to think as function's parameter as input of the function and
> return value as an output. Books usualy agree, so I guess it is a valid
> point.
> 
> OOP give us another parameter to play with : this. It act as a state
> that can be modified. UFCS is nice to extends that outside OOP. This is
> a way better alternative than out parameter.
> 
> Tuples are nice too. Since we have auto, this isn't a big deal.
> 
> Both should be preferred to out parameters IMO, because the later cannot
> be differentiated at the calling point and force the programer to refers
> to the function declaration all the time or use its - limited and
> sometime inaccurate - memory. This is something we want to avoid.

When you're looking to mutate existing variables in the caller, using out 
parameters results in cleaner code. Tuples are inherently messier, because you 
have to deal with multiple return values. They also often do poorly when you 
need to use the functional programming, because often you want all of the 
return values for later use but only want to pass _one_ of them to the 
function that you're passing the result to.

At other times, tuples are nicer - like when you actually _want_ the return 
value packed together (though often, if that's what you really want, a struct 
might be better). 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.

Both have value, though if you need a lot of either, you should probably 
consider whether a struct or class would suit what you're doing better.

- Jonathan M Davis