This clouds up your godoc with unnecessary names though. Why not just initialize a default value at the top of your function? You don't get the bare returns but it's a lot cleaner.
Does it? Names are documentation no? Eg, that's the one thing I actually like about named return values.
In my perfect world, we would have named return values by default, so then we could use them to document the return values, but never empty returns. Empty returns are the only problem with named return values Imo, as it's easy to accidentally slip values into the return that you didn't intend.
Though, I had always wondered about returning copies like Foo{} on every return.. guess I know now.
edit: As an aside, I should not dismiss your cluttering comment. I did so, because I feel it's unrelated to this exact topic. If named return values, something which by it's very nature conveys additional information, is cluttering the godocs, then that should be a bug, and filed/fixed accordingly. Imo.
This post specifically used very short uninformative names though, which was more to my point. If you're not going to use informative names, it shouldn't be part of the signature, especially when its barely any extra typing to do the same within the function body.
This is one of the few places Go fails to avoid the "multiple ways of doing the same thing" problem that many languages are overflowing with. It adds cognitive overhead and creates needless debate and afaik avoiding this has been one of the Go team's guiding principles.
