This may not be a good fit for this tool, and even if it is, it may be controversial. It may even be technically infeasible for reasons I haven't been able to imagine yet. So this is as much an RFC as a proposal.
Proposal
But to the meat of the matter: I'm proposing that gofumpt rewrite naked returns to no longer be naked. I think this can be a simple matter of copying the names of return values from the function signature to any naked return statements. Example:
func sum(a, b int) (result int) {
result = a+b
return
}
would be rewritten to:
func sum(a, b int) (result int) {
result = a+b
return result
}
Rationale
IMHO, naked returns are one of the worst features of Go. I know I'm not alone in this, although I haven't done any sort of formal survey. For a language that values readability, this feature seemingly always goes against that ideal. Granted, for trivially short functions (like my example above), the naked return doesn't really hurt readability that much. The problems arise for much longer functions. But even in these short cases, adding the return result doesn't seem to hurt readability, either.
The only argument I can think of in favor of naked returns is the popular "less typing". But by having a tool like gofumpt do this, those who like less typing can still have their way, without hurting readability.
Possible Problems
I've spent some time trying to find places where the simple rule of "copy the named return values to the naked return statement" might break things. I can't think of any. There are a few places where a naked return might be ambiguous, with regard to shadowed variables, but these are already prohibited by the compiler. So I think we can assume that any valid Go code can apply this rule safely.
This may not be a good fit for this tool, and even if it is, it may be controversial. It may even be technically infeasible for reasons I haven't been able to imagine yet. So this is as much an RFC as a proposal.
Proposal
But to the meat of the matter: I'm proposing that
gofumptrewrite naked returns to no longer be naked. I think this can be a simple matter of copying the names of return values from the function signature to any naked return statements. Example:would be rewritten to:
Rationale
IMHO, naked returns are one of the worst features of Go. I know I'm not alone in this, although I haven't done any sort of formal survey. For a language that values readability, this feature seemingly always goes against that ideal. Granted, for trivially short functions (like my example above), the naked return doesn't really hurt readability that much. The problems arise for much longer functions. But even in these short cases, adding the return result doesn't seem to hurt readability, either.
The only argument I can think of in favor of naked returns is the popular "less typing". But by having a tool like
gofumptdo this, those who like less typing can still have their way, without hurting readability.Possible Problems
I've spent some time trying to find places where the simple rule of "copy the named return values to the naked return statement" might break things. I can't think of any. There are a few places where a naked return might be ambiguous, with regard to shadowed variables, but these are already prohibited by the compiler. So I think we can assume that any valid Go code can apply this rule safely.