Hi Dave.
> The blame for this confusion comes from adding the special case, not from a
> limitation of the general function call syntax.
I see it differently. The limitation I'm referring to is "… arguments must be
single-valued expressions assignable to the parameter types of F …". I believe
that without this limitation both cases would work, no “special case” exception
would be needed, higher-order functions would be more fully implemented, and Go
would be more orthogonal.
The only downside is what Ian pointed out – potential confusion when used with
variadac functions. But worst case an exception could handle this. J
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Dave Cheney
Sent: 2017 January 25, Wed 22:12
To: golang-nuts
Subject: Re: [go-nuts] Is Go too strict for nesting function callings?
I think you misunderstand. The exception is this form
func f() (int, boo)
func g1(int, bool)
g1(f())
Not this form
func g2(int, int, bool)
g2(1, f())
The exception is the former form which is a special case for convenience. This
special case creates confusion when people try the second form. The blame for
this confusion comes from adding the special case, not from a limitation of the
general function call syntax.
On Thursday, 26 January 2017 12:28:34 UTC+11, John Souvestre wrote:
Hi Ian.
OK, I understand now.
Btw - I wasn't proposing adding an exception, but removing a limitation and the
exception due to it. :)
John
John Souvestre - New Orleans LA
-----Original Message-----
From: Ian Lance Taylor [mailto:ia...@golang.org <javascript:> ]
Sent: 2017 January 25, Wed 19:18
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Is Go too strict for nesting function callings?
On Wed, Jan 25, 2017 at 5:05 PM, John Souvestre <jo...@souvestre.com
<javascript:> > wrote:
>
> Thanks! I see both the limitation and the exception.
>
> Other than implementation complexity, is there a reason for the limitation of
> single-valued expressions? Is there some fundamental problem with allowing
> multi-valued expressions that I'm missing?
It's potentially confusing when used with variadic functions. If we
extend past function calls, it's potentially confusing when used with
multi-valued assignment statements. It's hard to make fully general
while avoiding confusion, and specific uses don't seem to arise often
enough in practice to justify adding more exceptions to the language.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
