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

41–50 of 146 posts

Re: Benefits of named return values in Go

#41

Post by Ao7bei3s »

19eightyfour wrote: post #37
cyphar wrote: post #27

Earlier quoted context omitted.

I'm fairly sure that almost every statically typed language has function definitions like that. C, C++, Java, Go, Rust and so on all have that style of function declaration. Named returns are a Go thing mainly because of defer.

How does defer interact with named returns?

As one would expect. The deferred code runs after the normal code in the function has ended, and before the calling code has resumed. Named return values are in scope and can be read and modified.

Try it and see: https://play.golang.org/p/1ozFWDj15a

Re: Benefits of named return values in Go

#42

Post by dullgiulio »

19eightyfour wrote: post #37
cyphar wrote: post #27

Earlier quoted context omitted.

I'm fairly sure that almost every statically typed language has function definitions like that. C, C++, Java, Go, Rust and so on all have that style of function declaration. Named returns are a Go thing mainly because of defer.

How does defer interact with named returns?

You can easily access and modify the named return variables from a deferred function body.

If you had a variable declared in a block just before return, then you return it, you have no way to modify it in defer.

I personally don't like this style of code, but I can see some uses.

Re: Benefits of named return values in Go

#43

Post by pjmlp »

obstinate wrote: post #11
edsrzf wrote: post #6

I normally hate it when people immediately trot out the old "premature optimization" quote, but it really applies here. Please don't go around naming all your returns just because today's compiler happens to generate better code with them. This is a compiler issue that I'm confident will be fixed one day, especially if you do the right thing and file an issue. But by all means, if you're profiling and your inner loop…

I dunno. A 30% code size win is non-trivial. I'm all for filing an issue first and seeing how likely it is that there is uptake from the dev team and desire to fix the problem. However, if no fix is forthcoming . . . code size has fairly well known effects on performance.

Unless it actually impacts the use case of the application, and has been confirmed by a profiler that is indeed the case, it is just cargo cult optimizations.

Re: Benefits of named return values in Go

#44

Post by _0w8t »

19eightyfour wrote: post #37
cyphar wrote: post #27

Earlier quoted context omitted.

I'm fairly sure that almost every statically typed language has function definitions like that. C, C++, Java, Go, Rust and so on all have that style of function declaration. Named returns are a Go thing mainly because of defer.

How does defer interact with named returns?

defer can refer to and change the return values. This is useful, for example, when the deferred code can trigger an error that one wants to return, https://play.golang.org/p/MBmy9OocAG

Re: Benefits of named return values in Go

#46

Post by 19eightyfour »

Ao7bei3s wrote: post #41
19eightyfour wrote: post #37

Earlier quoted context omitted.

How does defer interact with named returns?

As one would expect. The deferred code runs after the normal code in the function has ended, and before the calling code has resumed. Named return values are in scope and can be read and modified. Try it and see: https://play.golang.org/p/1ozFWDj15a

Cool. Can anything execute between the end of the deferer and the start of the deferred?

Re: Benefits of named return values in Go

#47

Post by 19eightyfour »

_0w8t wrote: post #44
19eightyfour wrote: post #37

Earlier quoted context omitted.

How does defer interact with named returns?

defer can refer to and change the return values. This is useful, for example, when the deferred code can trigger an error that one wants to return, https://play.golang.org/p/MBmy9OocAG

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?

Re: Benefits of named return values in Go

#48

Post by 19eightyfour »

dullgiulio wrote: post #42
19eightyfour wrote: post #37

Earlier quoted context omitted.

How does defer interact with named returns?

You can easily access and modify the named return variables from a deferred function body. If you had a variable declared in a block just before return, then you return it, you have no way to modify it in defer. I personally don't like this style of code, but I can see some uses.

Ok now I got they are in scope. About defer, could you think of it like defer makes a function into a function with multiple entry and exit points, possible to be stopped and resumed, like a coroutine?

Re: Benefits of named return values in Go

#49

Post by fwessels »

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 can, but just naming the return variable takes care of this.

Re: Benefits of named return values in Go

#50

Post by dullgiulio »

19eightyfour wrote: post #48
dullgiulio wrote: post #42

Earlier quoted context omitted.

You can easily access and modify the named return variables from a deferred function body. If you had a variable declared in a block just before return, then you return it, you have no way to modify it in defer. I personally don't like this style of code, but I can see some uses.

Ok now I got they are in scope. About defer, could you think of it like defer makes a function into a function with multiple entry and exit points, possible to be stopped and resumed, like a coroutine?

Ehm, not sure I understood, but I'd say no. Defer is just code that is executed in reverse order upon return from a fuction. It has nothing to do with coroutines. It's a cleaner way to write the usual C syntax of "goto cleanup_x" code.

Go coroutines (goroutines) are functions invoked with the "go" keyword. These cannot be stopped or resumed, but might be (possibly) executed on a different thread. In any case, they are not guaranteed to be executed immediately in the normal flow of the code.

Post reply on HN