Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/gofmt: proposal: place conditional single statement return on a single line (e.g. if err != nil { return err }) #60771

Closed
sparr opened this issue Jun 13, 2023 · 1 comment
Labels
error-handling Language & library change proposals that are about error handling. Proposal

Comments

@sparr
Copy link

sparr commented Jun 13, 2023

foo, err := bar()
if err != nil { return err }

Four years ago, #33113 was opened and quickly closed. In the intervening time, there have been dozens of proposals to change the language with the common intent to reduce the amount of boilerplate code around error handling, almost all of which have been rejected. I suggest that this amount of effort put in by so many people trying to find an acceptable route toward similar goals represents a compelling reason to reconsider that closure, and possibly at least part of a compelling reason to accept this proposal.

This proposal makes tangible progress toward a goal shared by at least most of those other proposals, without requiring any change to the language or syntax. It will make long series of calls with simple error checkin easier to read, and by extension also improve the readability of the surrounding code.

The core of this proposal is to change the formatting of a block that contains a single return statement, to put the statement and } on the same line as the {. Restricting this behavior to statements where one or all of the return values are present in the conditional for the block may be desirable. Restricting this behavior to statements where one or all of the return values were assigned in the statement prior to the conditional for the block may be desirable. Further specific examples and discussion of those details would likely be relevant to a design doc for this proposal.

A significant potential negative impact of this change would be a large amount of code churn across projects using gofmt. This change would likely affect almost every source file containing functions, across all packages and projects.

@sparr sparr added the Proposal label Jun 13, 2023
@ianlancetaylor
Copy link
Contributor

Thanks, but aside from #33113, we recently reviewed this idea again at #57645. I think that #57645 was recent enough that I am going to close this as a duplicate. Please comment if you disagree.

@ianlancetaylor ianlancetaylor closed this as not planned Won't fix, can't repro, duplicate, stale Jun 13, 2023
@ianlancetaylor ianlancetaylor added the error-handling Language & library change proposals that are about error handling. label Jun 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
error-handling Language & library change proposals that are about error handling. Proposal
Projects
None yet
Development

No branches or pull requests

2 participants