www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Named return type > Out parameters

reply xx <xx xx.com> writes:
Next in the series of "How about Go's ____":

(int var1, float var2) function();

is much nicer, logical and consistent than:

int function(out float var2);


Of course this requires multiple assignment, but that's another cool thing.
Nov 12 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Thu, Nov 12, 2009 at 5:42 PM, xx <xx xx.com> wrote:
 Next in the series of "How about Go's ____":

 (int var1, float var2) function();

 is much nicer, logical and consistent than:

 int function(out float var2);


 Of course this requires multiple assignment, but that's another cool thing.

Did go do away with the comma sequencing operator? I can't find it. That's the first thing D needs to do. Otherwise a,b = function() is difficult to make work. --bb
Nov 12 2009
parent reply =?UTF-8?B?IuOBruOBl+OBhOOBiyAobm9zaGlpa2EpIg==?= writes:
Bill Baxter さんは書きました:
 Did go do away with the comma sequencing operator?
 I can't find it.  That's the first thing D needs to do.
 
 Otherwise
    a,b = function()
 is difficult to make work.

How about redefining the comma operator as a "tuple constructor" with its precedence unchanged? In so doing, we may write: (int, int) func(int x, int y) { return y, x; } // tuple-to-tuple function // (int, int) is a type tuple, "int x, int y" a named type tuple, // and "y, x" an expression tuple. (int, int) t = func(0, 1); // t is a type-tuple-typed variable. int a, b; (a, b) = func(t); // (a, b) is an lvalue tuple. and f(0, 1) beautifully has the same semantics with f((0, 1)) by the tuple flattening.
Nov 12 2009
next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
のしいか (noshiika) wrote:
 Bill Baxter さんは書きました:
 Did go do away with the comma sequencing operator?
 I can't find it.  That's the first thing D needs to do.

 Otherwise
    a,b = function()
 is difficult to make work.

How about redefining the comma operator as a "tuple constructor" with its precedence unchanged? In so doing, we may write: (int, int) func(int x, int y) { return y, x; } // tuple-to-tuple function // (int, int) is a type tuple, "int x, int y" a named type tuple, // and "y, x" an expression tuple. (int, int) t = func(0, 1); // t is a type-tuple-typed variable. int a, b; (a, b) = func(t); // (a, b) is an lvalue tuple.

call me a pascal junkie, but I much prefer being able to write a,b = b,a;
 and f(0, 1) beautifully has the same semantics with f((0, 1)) by the
 tuple flattening.

In other news, I just ran a search on tango and phobos1, and found comma operator used 83 and 11 times, respectively. A little less than I expected.
Nov 12 2009
prev sibling parent grauzone <none example.net> writes:
のしいか (noshiika) wrote:
 Bill Baxter さんは書きました:
 Did go do away with the comma sequencing operator?
 I can't find it.  That's the first thing D needs to do.

 Otherwise
    a,b = function()
 is difficult to make work.

How about redefining the comma operator as a "tuple constructor" with its precedence unchanged? In so doing, we may write: (int, int) func(int x, int y) { return y, x; } // tuple-to-tuple function // (int, int) is a type tuple, "int x, int y" a named type tuple, // and "y, x" an expression tuple. (int, int) t = func(0, 1); // t is a type-tuple-typed variable. int a, b; (a, b) = func(t); // (a, b) is an lvalue tuple.

Very yes! Of course I'd prefer to be able to write "a, b = func(t);" in expressions. Too bad Andrei and Walter don't seem to think these are issues. Don't know how they can live with that Tuple!(...) crap.
 and f(0, 1) beautifully has the same semantics with f((0, 1)) by the 
 tuple flattening.

Tuple flattening is bad and should be removed as quickly as possible from D.
Nov 13 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"xx" <xx xx.com> wrote in message news:hdidi8$213s$1 digitalmars.com...
 Next in the series of "How about Go's ____":

 (int var1, float var2) function();

 is much nicer, logical and consistent than:

 int function(out float var2);


 Of course this requires multiple assignment, but that's another cool 
 thing.

I have always liked that idea, but the nice thing about "out" params is that you can overload on them, and D can't overload on return values (apperently there are problems with that). Anyone know if GoogleGo functions can be overloaded on return value? (Or if it even does function overloading at all, for that matter?)
Nov 12 2009
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20091113031715.GD8560 llucax.com.ar...
 Nick Sabalausky, el 12 de noviembre a las 22:13 me escribiste:
 "xx" <xx xx.com> wrote in message news:hdidi8$213s$1 digitalmars.com...
 Next in the series of "How about Go's ____":

 (int var1, float var2) function();

 is much nicer, logical and consistent than:

 int function(out float var2);


 Of course this requires multiple assignment, but that's another cool
 thing.

I have always liked that idea, but the nice thing about "out" params is that you can overload on them, and D can't overload on return values (apperently there are problems with that). Anyone know if GoogleGo functions can be overloaded on return value? (Or if it even does function overloading at all, for that matter?)

GoogleGo doesn't have function overloading at all.

Heh, you know, normally I would never think to question whether or not a language had function overloading ("Well hell, why don't I just ask if it has multiplication? That wouldn't be a dumb question at all!"), but something about GoogleGo (as I've decided I'm going to keep calling it) made me think "Umm...you may not want to assume that in this case...".
Nov 12 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

(Or if it even does function overloading at all, for that matter?)<

Recently I have shown here the style guide of the C++ code used by Google. There are many forbidden (or nearly forbidden) things, like function overloading. So a ""system language"" designed by Google probably will not have function overloading... ----------- Regarding the topic of this thread: I find named return arguments a little confusing, maybe I just need to get used to them. But I like the idea of multiple return arguments and a handy syntax to unpack such return values at the calling site. (I use this all the time in Python and sometimes in D1 too using auxiliary structs similar to the Tuple of Phobos2). Bye, bearophile
Nov 13 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Nick Sabalausky, el 12 de noviembre a las 22:13 me escribiste:
 "xx" <xx xx.com> wrote in message news:hdidi8$213s$1 digitalmars.com...
 Next in the series of "How about Go's ____":

 (int var1, float var2) function();

 is much nicer, logical and consistent than:

 int function(out float var2);


 Of course this requires multiple assignment, but that's another cool 
 thing.

I have always liked that idea, but the nice thing about "out" params is that you can overload on them, and D can't overload on return values (apperently there are problems with that). Anyone know if GoogleGo functions can be overloaded on return value? (Or if it even does function overloading at all, for that matter?)

GoogleGo doesn't have function overloading at all. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Never let a fool kiss you, or let a kiss fool you
Nov 12 2009
prev sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 13 Nov 2009 07:30:55 -0500, grauzone <none example.net> wrote:

 のしいか (noshiika) wrote:
 Bill Baxter さんは書きました:
 Did go do away with the comma sequencing operator?
 I can't find it.  That's the first thing D needs to do.

 Otherwise
    a,b = function()
 is difficult to make work.

with its precedence unchanged? In so doing, we may write: (int, int) func(int x, int y) { return y, x; } // tuple-to-tuple function // (int, int) is a type tuple, "int x, int y" a named type tuple, // and "y, x" an expression tuple. (int, int) t = func(0, 1); // t is a type-tuple-typed variable. int a, b; (a, b) = func(t); // (a, b) is an lvalue tuple.

Very yes! Of course I'd prefer to be able to write "a, b = func(t);" in expressions. Too bad Andrei and Walter don't seem to think these are issues. Don't know how they can live with that Tuple!(...) crap.
 and f(0, 1) beautifully has the same semantics with f((0, 1)) by the  
 tuple flattening.

Tuple flattening is bad and should be removed as quickly as possible from D.

Only type tuples are flattened. auto t = tuple(1,tuple(2,3)); doesn't flatten. As for syntax, I'd prefer using the slice operator, '..', since doing so facilitates multi-dimensional containers.
Nov 13 2009