digitalmars.D - Named return type

digitalmars.D - Named return type > Out parameters

xx <xx xx.com> Nov 12 2009

Bill Baxter <wbaxter gmail.com> Nov 12 2009

=?UTF-8?B?IuOBruOBl+OBhOOBiyAobm9zaGlpa2EpIg==?= Nov 12 2009

Ellery Newcomer <ellery-newcomer utulsa.edu> Nov 12 2009
grauzone <none example.net> Nov 13 2009

"Nick Sabalausky" <a a.a> Nov 12 2009

"Nick Sabalausky" <a a.a> Nov 12 2009
bearophile <bearophileHUGS lycos.com> Nov 13 2009

Leandro Lucarella <llucax gmail.com> Nov 12 2009
"Robert Jacques" <sandford jhu.edu> Nov 13 2009

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

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

=?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

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

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

"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

"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

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

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

"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

D Programming

C/C++ Programming

Other

digitalmars.D - Named return type > Out parameters