61–70 of 146 posts
I'm not familiar with Go and I'm confused by the fact that even though the returned variable is named, e.g. "ch", that name is never mentioned in the function body. What am I missing?
The named return value is default-initialised (zero-initialised) before the function body (you don't have to assign to it, you can just modify it in place), and if you don't explicitly return a different value it will be returned regardless of you using it or not.
I actually hate named return values. I'm relatively new to Go, but I like some of the ideas about it. Named return values is something about Go that I despise because it is absolutely misused in my opinion. For such an opinionated language, with some opinions that I don't agree with, this is one that I vehemently disagree with. It makes the code a lot harder to read, and you need to keep more memorized "magic" in you…
You can use non-bare returns with named return values, just mention the names in the return statement. This compiles to the same code as the bare return.
I'm a bit ambivalent about bare returns, but named return values are useful, especially in the presence of defer statements.
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?
add1 = map (+1)
add1 :: (Num a) => [a] -> [a]
add1 = map (+1)Earlier quoted context omitted.
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 feel like a lot of deferred errors go unhandled because inexperienced devs don't know that they can.
It's much easier to read code where there is a clean "return nil, fmt.Errorf(...)".
I actually hate named return values. I'm relatively new to Go, but I like some of the ideas about it. Named return values is something about Go that I despise because it is absolutely misused in my opinion. For such an opinionated language, with some opinions that I don't agree with, this is one that I vehemently disagree with. It makes the code a lot harder to read, and you need to keep more memorized "magic" in you…
I think they are pretty explicit and simpler, because there are defined in a single point of our code. Anyway, we probably have different backgrounds :)
Although it wasn't your point, what I don't like is mixing bare and named return. I think it's better to stick to one style or the other.
I look at these result functions and all I can think is, "Wow, it must be really delightful when you get a zero record back and what to know why your parser has a bug." I really hope these are didactic in nature and not a representation of industry best practice. 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…
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". :)
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.go (file taken at random)
[1] https://golang.org/doc/effective_go.html#named-results
Personally I use named returns heavily because it helps document what each return is used for. Which is particularly useful in IDEs like IntelliJ where you get the tooltip popup with the function parameters and returns. But frankly I find named returns just as useful when reading back old code on GitHub or even just in vi.
I also notice I'm not the only one who uses them in production code. Here are some popular packages by other talented Go developers (all .go files picked at random)[2][3]:
[2] https://github.com/kr/pty/blob/master/util.go (this package creates UNIX PTY files)
[3] https://github.com/chzyer/readline/blob/master/operation.go (readline package used by cockroachdb and Netflix)
In fact of the packages I checked, I could only find one package that didn't make heavy use of named returns[4]
[4] https://github.com/go-sql-driver/mysql/
So if they are frowned upon, I'd be interested to know more about who and why.
In my mind there are only two reasons to use named returns. The first is when writing interfaces, and you want to document the returned values in a nicer way (in addition to the godoc). This is mostly a taste thing and is not required.
However, the second one is required by the language and that is deferred function calls that interact with the return value of a function. If you want to have a deferred function call that does some cleanup but has to check the error value of the function (for example a cleanup that only runs if an error occurred) then you have to use named return values. If you want to have a deferred function that changes the return value of the main function then you also need named return values. This is a fairly annoying requirement of Go, but I understand why they felt it was necessary to do things that way to make it feel more explicit.
Other than that, in general named returns make functions harder to read (in my opinion). In a similar vein, I really don't like Ruby's or Rust's implicit returns (though at least Rust is less magical about it).
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.
I'm pretty sure Go does compile down to an IR, but it's little more than an abstraction over different architectures. I could be wrong.