March 02, 2012
On Friday, March 02, 2012 09:53:19 kennytm wrote:
> You can just chain with
> 
>     return doSomething(findSplit(haystack, needle)[0]);
> 
> if you just need the return value. Compare with 'out':
> 
>     R4 ignored;
>     R5 ignored2;
>     return doSomething(findSplit(haystack, needle, ignored, ignored2));
> 
> How do you chain with _partial_ amount of return values with 'out'?

If the function uses out, then you can chain the return value without losing the values which were assigned to the out arguments, but if you have a tuple, and you select one of the elements in the tuple to chain, you lose the others. The only way to get _all_ of the values in the tuple is to assign the tuple to a variable, in which case, you can't chain at all.

- Jonathan M Davis
March 02, 2012
Le 02/03/2012 11:10, Jonathan M Davis a écrit :
> On Friday, March 02, 2012 09:53:19 kennytm wrote:
>> You can just chain with
>>
>>      return doSomething(findSplit(haystack, needle)[0]);
>>
>> if you just need the return value. Compare with 'out':
>>
>>      R4 ignored;
>>      R5 ignored2;
>>      return doSomething(findSplit(haystack, needle, ignored, ignored2));
>>
>> How do you chain with _partial_ amount of return values with 'out'?
>
> If the function uses out, then you can chain the return value without losing
> the values which were assigned to the out arguments, but if you have a tuple,
> and you select one of the elements in the tuple to chain, you lose the others.
> The only way to get _all_ of the values in the tuple is to assign the tuple to
> a variable, in which case, you can't chain at all.
>
> - Jonathan M Davis

But you are assigning to a variable, you just declare it before. Additionally, you loose all possibility to use auto.
March 02, 2012
Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> On Friday, March 02, 2012 09:53:19 kennytm wrote:
>> You can just chain with
>> 
>>     return doSomething(findSplit(haystack, needle)[0]);
>> 
>> if you just need the return value. Compare with 'out':
>> 
>>     R4 ignored;
>>     R5 ignored2;
>>     return doSomething(findSplit(haystack, needle, ignored, ignored2));
>> 
>> How do you chain with _partial_ amount of return values with 'out'?
> 
> If the function uses out, then you can chain the return value without losing the values which were assigned to the out arguments, but if you have a tuple, and you select one of the elements in the tuple to chain, you lose the others. The only way to get _all_ of the values in the tuple is to assign the tuple to a variable, in which case, you can't chain at all.
> 
> - Jonathan M Davis

I see what you mean. However, this is useful only when you know one of the return value is special, and make the rest 'out' parameters, e.g.

    File openFile(string fn, string mode, out ErrorCode errCode);

because the API designer know people seldom focus on the 'errCode'. But if not all return values are considered unimportant (such as findSplit and remquo), randomly making some of them as the 'out' parameter just make the normal use cases more messy.

Besides, you can't use type inference with 'out' parameters. You don't actually know the types R4 and R5 in my findSplit2 example.
March 02, 2012
On Friday, 2 March 2012 at 10:13:17 UTC, Jonathan M Davis wrote:
> If the function uses out, then you can chain the return value without losing
> the values which were assigned to the out arguments, but if you have a tuple,
> and you select one of the elements in the tuple to chain, you lose the others.
> The only way to get _all_ of the values in the tuple is to assign the tuple to
> a variable, in which case, you can't chain at all.
>
> - Jonathan M Davis

Sure, but due to D's syntax which doesn't distinguish in/out/ref params in a function call, this is quite confusing to read: when you read f(x,y) which is in, which is out? If D's syntax was f(x,@y) (@ to distinguish out or ref parameter), this would be easy to read, but this isn't the case.

At least with tuples you don't have this issue.

Not that I consider tuples always the good answer: for the common use case where you want to return an error code and a result, the Maybe "monad" is better..

BR,
renoX





March 02, 2012
On Friday, March 02, 2012 12:59:43 kennytm wrote:
> Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > On Friday, March 02, 2012 09:53:19 kennytm wrote:
> >> You can just chain with
> >> 
> >> return doSomething(findSplit(haystack, needle)[0]);
> >> 
> >> if you just need the return value. Compare with 'out':
> >> R4 ignored;
> >> R5 ignored2;
> >> return doSomething(findSplit(haystack, needle, ignored, ignored2));
> >> 
> >> How do you chain with _partial_ amount of return values with 'out'?
> > 
> > If the function uses out, then you can chain the return value without losing the values which were assigned to the out arguments, but if you have a tuple, and you select one of the elements in the tuple to chain, you lose the others. The only way to get _all_ of the values in the tuple is to assign the tuple to a variable, in which case, you can't chain at all.
> > 
> > - Jonathan M Davis
> 
> I see what you mean. However, this is useful only when you know one of the return value is special, and make the rest 'out' parameters, e.g.
> 
> File openFile(string fn, string mode, out ErrorCode errCode);
> 
> because the API designer know people seldom focus on the 'errCode'. But if not all return values are considered unimportant (such as findSplit and remquo), randomly making some of them as the 'out' parameter just make the normal use cases more messy.
> 
> Besides, you can't use type inference with 'out' parameters. You don't actually know the types R4 and R5 in my findSplit2 example.

It's not like using out is fantastic and tuple sucks. They both have pros and cons. My point is that it's not the case that always returning tuples is better, which seems to be the point that Bearophile is trying to push. There _are_ downsides to returning tuples. Whether a tuple or an out parameter is better depends on the function and the context in which it is used.

- Jonathan M Davis
March 02, 2012
"Jonathan M Davis" <jmdavisProg@gmx.com> wrote:

> It's not like using out is fantastic and tuple sucks. They both have pros and cons. My point is that it's not the case that always returning tuples is better, which seems to be the point that Bearophile is trying to push. There _are_ downsides to returning tuples. Whether a tuple or an out parameter is better depends on the function and the context in which it is used.
> 
> - Jonathan M Davis

bearophile's example (frexp, remquo) are good examples where tuple return is better than 'out' parameters though. Another Phobos function, I think, which should use 'out' instead of Tuples is:

-  std.file.getTimes (have the two 'out' parameters, and the function
itself returns 'void'!)

While some functions should remain using 'out':

- std.stream.InputStream.read (due to overloading)

And of course the extern(C) functions need to use 'out' instead of Tuple
return :)
March 02, 2012
Has anyone seen my recent thread about using the if+auto feature and
opCast(bool)? It's not related to tuples but I thought it was a cool D
feature. I admit I named the thread a pretty stupid name, but it was 6
AM when I posted it :)
(http://forum.dlang.org/thread/mailman.195.1330399006.24984.digitalmars-d@puremagic.com)
1 2 3
Next ›   Last »