Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Benefits of named return values in Go

blog.minio.io

Post reply on HN
Print view View original

71–80 of 146 posts

Re: Benefits of named return values in Go

#71

Post by dom0 »

bradfitz wrote: post #31
runeks wrote: post #26

Earlier quoted context omitted.

I'm surprised Go doesn't compile down to an IR language where these differences in syntax are represented in a single manner. Seems like different ways to write the same thing.

It increasingly does. But it's been a process. Go 1.5 was the first self-hosting release, with the Go compiler auto-translated from C to Go. But it was still fundamentally Ken's C compiler in Go syntax. Every release since (Go 1.6, Go 1.7, Go 1.8, Go 1.9) has been cleaning it up and making it more Go like and less C like. Meanwhile, the backend was also retrofitted. Go 1.7 included an SSA backend for amd64 ( https://…

Why does Go not use LLVM? Are there technical reasons to reinvent the wheel, or is it just because LLVM is Apple's pet?

Re: Benefits of named return values in Go

#73

Post by _0w8t »

dullgiulio wrote: post #53
19eightyfour wrote: post #47

Earlier quoted context omitted.

Is that actually returning err as the deferred return value of test? In other words, to the caller of test it appears test returns the result of the deferred?

Deferred functions don't return anything. You can modify the values that are returned by the parent function, and those will be returned as the deferred function modified them.

Yep, and one cannot simulate that with local variables. In Go "return v" copies v into the return location before calling the deferred code. If that location is not named, the deferred function has no way to change it, see https://play.golang.org/p/Opg4XI08P7

Re: Benefits of named return values in Go

#74

Post by cyphar »

laumars wrote: post #67
weberc2 wrote: post #32

Earlier quoted context omitted.

For the most part named returns are frowned upon, and while it is admittedly an oddity in the language, having one oddity is still achieving the stated goal of "few surprises". :)

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…

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 magical in comparison).

[1]: https://github.com/golang/go/wiki/CodeReviewComments#named-r...

Re: Benefits of named return values in Go

#75

Post by pkroll »

dom0 wrote: post #71
bradfitz wrote: post #31

Earlier quoted context omitted.

It increasingly does. But it's been a process. Go 1.5 was the first self-hosting release, with the Go compiler auto-translated from C to Go. But it was still fundamentally Ken's C compiler in Go syntax. Every release since (Go 1.6, Go 1.7, Go 1.8, Go 1.9) has been cleaning it up and making it more Go like and less C like. Meanwhile, the backend was also retrofitted. Go 1.7 included an SSA backend for amd64 ( https://…

Why does Go not use LLVM? Are there technical reasons to reinvent the wheel, or is it just because LLVM is Apple's pet?

First part of the "Implementation" section: they thought it was too large and slow for their compiler speed goals.

https://golang.org/doc/faq#Implementation

Re: Benefits of named return values in Go

#76

Post by frou_dh »

mioelnir wrote: post #45

I very, very rarely use named return values. My usual go-to problem is when one of the return values is an `error` that I want to set inside `recover()`.

Surprised to find this not mentioned in the article and buried in comments. It's the first thing that comes to my mind as not merely a benefit, but an essential role played by the named returns.

Re: Benefits of named return values in Go

#77

Post by Gonzih »

013a wrote: post #22

I'm not the most proficient Go developer, but aren't the two examples doing two different things? In the first way, each branch allocates its own objectInfo struct. In the second way, all the branch exits share the same single objectInfo struct which I assume is implicitly initialized to the zero value by the compiler. Functionally these are the same, but couldn't you achieve the same results without named return val…

Yes, you are correct. Doing var return MyStruct {} at the beginning of the function would do exactly the same thing as naming return value.

Re: Benefits of named return values in Go

#78

Post by justinclift »

laumars wrote: post #67
weberc2 wrote: post #32

Earlier quoted context omitted.

For the most part named returns are frowned upon, and while it is admittedly an oddity in the language, having one oddity is still achieving the stated goal of "few surprises". :)

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…

Definitely agreed. Since getting into using Gogland (the JetBrains Go IDE), I'm using named return values much more because the name is useful in the pop-up help. I don't need to look up function docs anywhere near as often.

Re: Benefits of named return values in Go

#79

Post by heythere124 »

pcwalton wrote: post #56
bradfitz wrote: post #31

Earlier quoted context omitted.

It increasingly does. But it's been a process. Go 1.5 was the first self-hosting release, with the Go compiler auto-translated from C to Go. But it was still fundamentally Ken's C compiler in Go syntax. Every release since (Go 1.6, Go 1.7, Go 1.8, Go 1.9) has been cleaning it up and making it more Go like and less C like. Meanwhile, the backend was also retrofitted. Go 1.7 included an SSA backend for amd64 ( https://…

Just for what it's worth, the way I'd fix that problem in the compiler would be to implement dead store elimination via global value numbering. With trivial alias analysis, the compiler would be able to detect that the result of the "duffzero" instruction (which I assume is a memset) is always killed by the "duffcopy" instructions and would eliminate it. See this article for how it's done in LLVM: http://blog.llvm.or…

Not my area of expertise and it is yours, but if you eliminate a zero instruction before a copy instruction how can you be sure that doesn't affect other threads?

  var x Int
  // Pass x to a thread by reference
  x = 0
  time.Sleep(1000)
  x = 1

Re: Benefits of named return values in Go

#80

Post by KayEss »

ryeguy wrote: post #35
19eightyfour wrote: post #19

Earlier quoted context omitted.

I had a bit of a play around with it. It's pretty powerful being able to see in one line ( or possibly multi line ) It really hammers home the concept that a function is a transformation, and of what into what. And I think this syntax would probably encourage pure functions. And it's so useful to allocate the return in the top line. I really like go.

What language that has static types doesn't have the func, params, and return type in one line?

C++ ends up with three forms (of course it does):

Normal C style declaration

    int foo() { return 2; }
Trailing return type. Useful when the return type depends on the parameter types, or is inside the namespace of the function

    auto foo() -> int { return 2; }
Automated type deduction. Increasingly the choice when possible

    auto foo() { return 2; }
Post reply on HN