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

11–20 of 146 posts

Re: Benefits of named return values in Go

#11

Post by obstinate »

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.

Re: Benefits of named return values in Go

#14

Post by alexhornbake »

19eightyfour wrote: post #7

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 retu…

Naming 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
  }

Re: Benefits of named return values in Go

#15

Post by bradfitz »

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 filed a Go bug: https://github.com/golang/go/issues/20859

We should just fix the compiler.

Re: Benefits of named return values in Go

#17

Post by 19eightyfour »

piinbinary wrote: post #10
19eightyfour wrote: post #7

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 retu…

It 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 This can also be used to return the default value for a type by never assigning anything to the return value.

Okay, 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

I was also looking for a "spread" / ... operator, but couldn't see a way to do that.

Re: Benefits of named return values in Go

#19

Post by 19eightyfour »

alexhornbake wrote: post #14
19eightyfour wrote: post #7

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 retu…

Naming 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 := &objectInf…

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.

Re: Benefits of named return values in Go

#20

Post by gizmo686 »

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.

A 30% code size reduction in code that does little other than construct and return a value. I have certainly seen individual functions where this is the case, but across an entire program, you will not get anywhere near 30% size reduction.

Having said that, this is certainly something that should be fixed in the compiler.

On a related note, in the final assembly, the compiler could also have optimized the 4 RETs into 1, then optimized away all of the conditionals, turning the sample code into the equivilent of "return objectInfo()"). Of course, in a real example, these optimizations would not be possible; but they do show that these reduced cases are not the best way of benchmarking performance.

Post reply on HN