I feel the opposite. I view named returns as documentation of a function's
parameters. I'm constantly amazed by the (correct) emphasis placed on using
appropriate names for calling parameters, but not for the return parameters.
The goal is that I shouldn't have to read a function's code to use the
function, right?
So how can the disparity be justified? Oh, and the longer the function is the
more benefit there is to using them.
John
John Souvestre - New Orleans LA
-----Original Message-----
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of Ian Lance Taylor
Sent: 2017 February 21, Tue 16:13
To: andrew.penneba...@gmail.com
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Trying to understand := and named return values
On Tue, Feb 21, 2017 at 1:46 PM, <andrew.penneba...@gmail.com> wrote:
> Seems like named returns + if/for/switch initializers = a shadowing
> nightmare. I wish the Go compiler emitted a loud warning on shadowing, as
> this is a dangerously subtle problem out there.
Yes, named returns may have been a mistake. Only use them in very
very short functions.
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.
