On Wednesday, February 22, 2017 at 3:39:58 PM UTC+2, Marvin Renich wrote: > > On Tue, Feb 21, 2017 at 1:46 PM, <andrew.p...@gmail.com <javascript:>> > 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. > > * Ian Lance Taylor [170221 16:13]: > > Yes, named returns may have been a mistake. Only use them in very > > very short functions. > > * John Souvestre <jo...@souvestre.com <javascript:>> [170221 21:46]: > > 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? > > I agree with the John and the others that named return variables are a > good feature. > > The confusion is not because of the named returns, but because the := > notation used with multiple variables on the left combines declaration > and simple assignment without allowing, much less requiring, the > programmer to explicitly identify which variables are being declared and > which are simply being assigned a new value. This is relevant when := > is used at the block scope as well as in if/for/switch initializers. > > ...Marvin > >
does it sounds good to disable (in specs) named return vars shadowing ? Djadala -- 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.
