Earlier quoted context omitted.
It doesn't change the behavior of the return keyword, though. It adds a case, but it's an orthogonal case; if you have a function that returns anything, a bare return can only be using the named return values. My position is that I'm OK with saying "only use this if you need to screw with the return values via defer, and thus, the presence of named return values can be reliably inferred to mean that someone is using…
Without a named keyword, a void function can use the return keyword to terminate control flow conditionally. So it's only orthogonal in the case of a function with a typed return value. Which is fine. I have no problem with it. I'm a Haskell/ Clojure/Erlang/TypeScript/CL developer, so I'm used to this. But golang users beat me over the head with the "simplicity" of Go and use examples of Haskell and Clojure having le…
A few direct counterarguments:
* Named returns doesn't change the nature of the return statement. In fact you can still use return with locally scoped variables even with named returns (example below).
// This is only an example of overriding the default return.
// I'm not suggesting people write code like this!
func StrToBool(s string) (b bool) {
if s == "true" {
return true
}
return
}
At the end of the day named returns do provide some benefit eg when writing public APIs so other users can see - at a glance - what inputs and what returns a particular function takes. But like any feature in any language, a bad developer will easily find ways to abuse it.