21–30 of 146 posts
I went into reading this expecting that use case but was saddened it was not mentioned. The use case the author does give is kind of meh, I find it to be harder to understand what is going on than returning as usual, and that's worse than the slight supposed compiler gain is worth.
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 values by just allocating a single objectInfo at the top of the function and returning it?
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.
For me, the biggest reason I use named parameters is when something I'm ’defer’ring can fail. You can set your err return value within your defer only if it's named. I went into reading this expecting that use case but was saddened it was not mentioned. The use case the author does give is kind of meh, I find it to be harder to understand what is going on than returning as usual, and that's worse than the slight supp…
For me, the biggest reason I use named parameters is when something I'm ’defer’ring can fail. You can set your err return value within your defer only if it's named. I went into reading this expecting that use case but was saddened it was not mentioned. The use case the author does give is kind of meh, I find it to be harder to understand what is going on than returning as usual, and that's worse than the slight supp…
This is really a Go wart, in my opinion. Go forces you into this pattern, because there's no other way if you want to use defers. So while it's true that it's a legit use of named return values, it's an unfortunate one, too.
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.
Earlier quoted context omitted.
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.
Named returns are a Go thing mainly because of defer.
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…
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?
Earlier quoted context omitted.
I filed a Go bug: https://github.com/golang/go/issues/20859 We should just fix the compiler.
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.