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.

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

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.

"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?)

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

のしいか (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.

"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...".

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

のしいか (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.

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.
>>  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.

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.