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.
