digitalmars.D - Named return type > Out parameters
- xx (5/5) Nov 12 2009 Next in the series of "How about Go's ____":
- Bill Baxter (7/12) Nov 12 2009 Did go do away with the comma sequencing operator?
- =?UTF-8?B?IuOBruOBl+OBhOOBiyAobm9zaGlpa2EpIg==?= (15/21) Nov 12 2009 How about redefining the comma operator as a "tuple constructor"
- Ellery Newcomer (5/32) Nov 12 2009 call me a pascal junkie, but I much prefer being able to write
- grauzone (6/32) Nov 13 2009 Very yes! Of course I'd prefer to be able to write "a, b = func(t);" in
- Robert Jacques (5/33) Nov 13 2009 Only type tuples are flattened. auto t = tuple(1,tuple(2,3)); doesn't
- Nick Sabalausky (6/12) Nov 12 2009 I have always liked that idea, but the nice thing about "out" params is ...
- Leandro Lucarella (8/27) Nov 12 2009 GoogleGo doesn't have function overloading at all.
- Nick Sabalausky (7/31) Nov 12 2009 Heh, you know, normally I would never think to question whether or not a...
- bearophile (6/7) Nov 13 2009 Recently I have shown here the style guide of the C++ code used by Googl...
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
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
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
のしいか (noshiika) wrote:Bill Baxter さんは書きました:call me a pascal junkie, but I much prefer being able to write a,b = b,a;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.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
のしいか (noshiika) wrote:Bill Baxter さんは書きました: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.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.Tuple flattening is bad and should be removed as quickly as possible from D.
Nov 13 2009
On Fri, 13 Nov 2009 07:30:55 -0500, grauzone <none example.net> wrote:のしいか (noshiika) wrote: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.Bill Baxter さんは書きました: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.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.Tuple flattening is bad and should be removed as quickly as possible from D.
Nov 13 2009
"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
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...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 youNext 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
"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: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..."."xx" <xx xx.com> wrote in message news:hdidi8$213s$1 digitalmars.com...GoogleGo doesn't have function overloading at all.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
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