Benefits of named return values in Go • Hacker News Board

Re: Benefits of named return values in Go

#101

Post by KirinDave » Fri, Jun 30, 2017, 2:37 PM UTC

laumars wrote: post #81

cyphar wrote: post #74

Earlier quoted context omitted.

The Go code review document gives a brief comment about when they like and don't like to use them[1]. Personally the only time I find them to be acceptable is when you have to reference a returned value in a defer. All other usages are questionable, though this is a taste thing and is likely because of my dislike in it's usage as a way of omitting a `var` in a function body (and also the fact that naked returns are m…

I don't think naked returns are any more magical than when you just drop a variable name in there. Either way, when you read a return statement you'll want to re-read the code to find the context of that return. The only difference is with named returned the variable is declared in the function declaration rather than the body of code. So it's definitely just a preference thing there. My coding style is to try and av…

> Either way, when you read a return statement you'll want to re-read the code to find the context of that return.

That's the ugly part of this feature. It adds one more place where you need to check.

Also my hair gets paler and my body grows weak thinking about using defer with named return values. Isn't Go supposed to easy to read? Isn't that like it's principle virtue?

Re: Benefits of named return values in Go

#102

Post by KirinDave » Fri, Jun 30, 2017, 2:38 PM UTC

cyphar wrote: post #33

KirinDave wrote: post #29

I look at these result functions and all I can think is, "Wow, it must be really delightful when you get a zero record back and what to know why your parser has a bug." I really hope these are didactic in nature and not a representation of industry best practice. Why not just declare a record in scope and return that? Why rely on a sneaky little piece of syntax tucked away in the return value? Aren't gophers supposed…

> Why not just declare a record in scope and return that? Why rely on a sneaky little piece of syntax tucked away in the return value? Aren't gophers supposed to be all about a regular language with few surprises? It's not a sneaky piece of syntax, in fact it is required to use that syntax if you want to reference or modify the return value of a function in a deferred function call. I don't like the syntax and hate t…

If you have long function and the addition of a single character up top at the right changes the behavior of the return keyword?

I've hated this feature since I learned about it. Its existence is one of the many reasons I dismiss arguments about Go being easy to read.

Re: Benefits of named return values in Go

#103

Post by jerf » Fri, Jun 30, 2017, 2:41 PM UTC

KirinDave wrote: post #100

jerf wrote: post #98

Earlier quoted context omitted.

"Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature." /r/golang consensus is against using named values. I disagree with it, but the consensus is there. Or at least I think that at the very least named return values should indicate that someone is doing someth…

I think changing the behavior of the return keyword is a bit worrisome given the often long nature of Go functions. The way return works is dictated by the existence of a perhaps bad name in the start of the function declaration, in a place most likely to fall off screen in a split editor scenario. I called it sneaky because I think it's hard to see. I don't get the value of this technique over, say, naming and retur…

It doesn't change the behavior of the return keyword, though. It adds a case, but it's an orthogonal case; if you have a function that returns anything, a bare return can only be using the named return values.

My position is that I'm OK with saying "only use this if you need to screw with the return values via defer, and thus, the presence of named return values can be reliably inferred to mean that someone is using defer to change the values", but to say "They're always a bad idea and never use them." is way too strong and dogmatic. They're in the language for a reason, because otherwise errors in defer statements could only be A: ignored or B: panic'ed, which is a far bigger problem in reality than the named return parameters.

Re: Benefits of named return values in Go

#104

Post by zaphar » Fri, Jun 30, 2017, 2:44 PM UTC

This isn't necessarily an argument for named return values. It's an argument for declaring your return value up front and even then it's really just an argument for Go to do a better job in the compiler here.

Named return values are one way to declare your return value up front but you could just as easily have had a oi := objectInfo{} line at the top of your function too with the same effect.

Re: Benefits of named return values in Go

#105

Post by KirinDave » Fri, Jun 30, 2017, 2:48 PM UTC

jerf wrote: post #103

KirinDave wrote: post #100

Earlier quoted context omitted.

I think changing the behavior of the return keyword is a bit worrisome given the often long nature of Go functions. The way return works is dictated by the existence of a perhaps bad name in the start of the function declaration, in a place most likely to fall off screen in a split editor scenario. I called it sneaky because I think it's hard to see. I don't get the value of this technique over, say, naming and retur…

It doesn't change the behavior of the return keyword, though. It adds a case, but it's an orthogonal case; if you have a function that returns anything, a bare return can only be using the named return values. My position is that I'm OK with saying "only use this if you need to screw with the return values via defer, and thus, the presence of named return values can be reliably inferred to mean that someone is using…

Without a named keyword, a void function can use the return keyword to terminate control flow conditionally. So it's only orthogonal in the case of a function with a typed return value.

Which is fine. I have no problem with it. I'm a Haskell/ Clojure/Erlang/TypeScript/CL developer, so I'm used to this. But golang users beat me over the head with the "simplicity" of Go and use examples of Haskell and Clojure having lexical scopes change common keywords as examples of the "excessive complexity of !Golang".

I'm not asking you to defend an argument you didn't make, but I think Go folks need to own that this is actually a code smell for something that could be done differently a scoped variable.

Re: Benefits of named return values in Go

#106

Post by [deleted] » Fri, Jun 30, 2017, 2:53 PM UTC

artursapek wrote: post #93

pbnjay wrote: post #9

This clouds up your godoc with unnecessary names though. Why not just initialize a default value at the top of your function? You don't get the bare returns but it's a lot cleaner.

This is one of the few places Go fails to avoid the "multiple ways of doing the same thing" problem that many languages are overflowing with. It adds cognitive overhead and creates needless debate and afaik avoiding this has been one of the Go team's guiding principles.

[deleted]

Re: Benefits of named return values in Go

#107

Post by camus2 » Fri, Jun 30, 2017, 2:56 PM UTC

jerf wrote: post #98

laumars wrote: post #67

Earlier quoted context omitted.

Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature. In fact named returns appear all over the Go source code itself[0] and the Effective Go section on named returns[1] seems positive about their usage. [0] https://github.com/golang/go/blob/master/src/os/file.g…

"Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature." /r/golang consensus is against using named values. I disagree with it, but the consensus is there. Or at least I think that at the very least named return values should indicate that someone is doing someth…

> /r/golang consensus is against using named values.

/r/golang is a toxic subreddit and I wouldn't take anything said there for face value. Dave Cheney deleted his account there and the go team itself wanted to delete that subreddit. So no, /r/golang represents only /r/golang and certainly not the go community as a whole.

/r/golang favorite pass time is to take some piece of code or a library and humiliate its author(s) publicly for not writing go like /r/golang wants go to be written.

Re: Benefits of named return values in Go

#108

Post by KirinDave » Fri, Jun 30, 2017, 3:03 PM UTC

camus2 wrote: post #107

jerf wrote: post #98

Earlier quoted context omitted.

"Are they actually frowned upon? I've been writing Go for a few years now and while I acknowledge there will be blind spots in my knowledge, this is still the first I've heard against using that language feature." /r/golang consensus is against using named values. I disagree with it, but the consensus is there. Or at least I think that at the very least named return values should indicate that someone is doing someth…

> /r/golang consensus is against using named values. /r/golang is a toxic subreddit and I wouldn't take anything said there for face value. Dave Cheney deleted his account there and the go team itself wanted to delete that subreddit. So no, /r/golang represents only /r/golang and certainly not the go community as a whole. /r/golang favorite pass time is to take some piece of code or a library and humiliate its author…

Sounds like #scala used to be.

Re: Benefits of named return values in Go

#109

Post by camgunz » Fri, Jun 30, 2017, 3:04 PM UTC

I went this route a little for a side project because it's natural to pass up errors via `err` this way, but I found out you have to have a naked return at the end of your function no matter what. I can't at all think of a reason for this; is there one?

Re: Benefits of named return values in Go

#110

Post by andreasgonewild » Fri, Jun 30, 2017, 3:13 PM UTC

I feel like it was a mistake to allow mixing the two styles inside the same function. I ran into enough issues with non-initialized returns during my adventures in Go to stop using named return parameters completely. To me, this feature has the same appeal as JavaScript's optional semicolons; or Pascals with-statements; convenience at the price of reliability and correctness.