5 ms·
I was going to post "But JS has this: return { named_var_1, named_var_2 } const { named_var_1, named_var_2 } = f() But then I read the article. I do
by 19eightyfour 9y ago
I was going to post "But JS has this:
return { named_var_1, named_var_2 }
const { named_var_1, named_var_2 } = f()
But then I read the article.
I don't know really what is going on in this article on a quick reading, but it builds by existing sense that go is a really cool language that I ought to get into.
I have no idea if anyone wants to help me understand, but in the last part where he changes to use a named return parameter, he says, you may also "enjoy the cleaner look of the source code, too". To me the only difference I see is the return name, to the right of the existing function signature. What was I missing that makes this actually cleaner?
- piinbinary 9y agoIt allows you to assign to the "return variables" inside the function, then just return without naming all the returned values at every return. e.g. https://play.golang.org/p/gdac5QR-wW https://play.golang.org/p/gdac5QR-wW This can also be used to return the default value for a type by never assigning anything to the return value.
- 19eightyfour 9y agoOkay, I think I get it. The format / syntax is pretty easy, simple and clean. I like it. I added a new function that takes two params and returns param, so I think I get this naming the returns now. https://play.golang.org/p/7bfiSqKY_w https://play.golang.org/p/7bfiSqKY_w I was also looking for a "spread" / ... operator, but couldn't see a way to do that.
- alexhornbake 9y agoNaming the return value in the function signature will both allocate the named variable, as well as make it the default variable to return. Returning a new unnamed variable for every return will cause all of the unnamed variables to be allocated. It's interesting, I don't use this feature of the language... my default way to write this would have been: func NoNamedReturnParams(i int) (*objectInfo) { obj := &objectInfo{} if i == 1 { // Do one thing return obj } if i == 2 { // Do another thing return obj } if i == 3 { // Do one more thing still return obj } // Normal return return obj }
- 19eightyfour 9y agoI had a bit of a play around with it. It's pretty powerful being able to see <func name> <params type> <return type> 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.
- cyphar 9y agoI'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.
- 19eightyfour 9y agoHow does defer interact with named returns?
- Ao7bei3s 9y agoAs 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 https://play.golang.org/p/1ozFWDj15a
- 19eightyfour 9y agoCool. Can anything execute between the end of the deferer and the start of the deferred?
- dullgiulio 9y agoAnything as from any other thread/goroutine? Yes of course, all shared data must be protected from races. If you mean in the same context then, no.