Hacker News new | ask | show | jobs
by pkulak 4571 days ago
Named return parameters are unfortunate. Probably better to never use them unless you have to (like if you are "catching" a panic). Otherwise, I think you are nitpicking a bit.
3 comments

I don't mind using named returns a lot--they can help to document, and sometimes they save you a declaration you were going to do in the method body anyway.

There are times they can be redundant (Sum(ints) does not need its return value named), or make the code less clear, or they indicate that you're trying to work around having overcomplicated methods by documenting them--I'm not saying always use them. But I don't try to avoid them.

That usage with recover would be to be able to set return parameters that might otherwise be returned as their zero values, correct?
Exactly. You can't return from the outer function in a defer, but you do have access to named return values. It's a bit of a kludge.
What's wrong with named return parameters?
http://golang.org/doc/effective_go.html#named-results

It's far more convenient looking at the function deceleration and knowing what comes and goes instead of hunting for return statements.