Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
proposal: Go 2: reduce noise in return statements that contain mostly zero values #21182
Closed in favor of a universal zero value, see #19642 (comment)
In return statements, allow
This is best described by example:
Given the function signature
The following is invalid:
It is common for a function with multiple return values to return only one non-zero result when returning early due to errors.
This creates several annoyances of varying degrees.
When writing the code one or more zero values must be manually specified. This is at best a minor annoyance and not worth a language change.
Editing the code after changing the type of, removing one of, or adding another return value is quite annoying but the compiler is fast enough and helpful enough to largely mitigate this.
For both of the above external tooling can help: https://github.com/sqs/goreturns
However, the unsolved problem and motivation for the proposal is that it is quite annoying to read code like this. When reading
This can be handled entirely with the naked return, but that has greater readability issues, can lead too easily to returning the wrong or partially constructed values, and is generally (and correctly) frowned upon in all but the simplest of cases.
Having a universal zero value, like
This has the benefit of introducing nothing new to the language. It reduces the annoyances caused by writing and editing the return values by creating a single place to write/edit the return values. It helps a lot with the reading but still has some boilerplate to read and take in. However, this pattern could be sufficient.
This proposal would complicate the grammar for the return statement and hence the go/ast package so it is not backwards compatible in the strict Go 1 sense, but as the construction is currently illegal and undefined it is compatible in the the Go 2 sense.
Only allow a single value other than
Only allow it on the left (
Do not allow it in the middle (
While these restrictions are likely how it would be used in practice anyway, I don't see a need for the limitations. If it proves troublesome in practice it could be flagged by a linter.
Allow it to replace zero or more values making the below legal:
This would allow easier writing and editing but hurt the readability by implying that there were other possible returns. It would also make this non-sequitur legal:
I like this idea, but I can't think of any place where I'd use it for anything other than filling in all but the last value. Given that, I think one could reasonably make it a little less general and allow only this form (allowing any expression instead of err, naturally)
Note the lack of comma. I'm not sure whether it's better with a space before "err" or not.
@OneOfOne Naked returns are fine for very short functions but are harder to scale: it gets too easy to accidentally return partially constructed values or the wrong err because of shadowing. Other than that, or maybe because of that, I like the explicit syntax better. A naked return says "go up to the function signature to see what can be returned, then trace through the code to see what actually gets returned here" whereas
@rogpeppe that was the original syntax proposed that I based this proposal off of. I don't like it because it appears to be a spread operator common in dynamic languages so it's a bit confusing. Having the comma makes it superficially more similar to "⋯" in mathematical writing and with like purpose. I agree that this would almost always be used as
@jimmyfrasche I just don't see that it would ever be used, and given that, the comma seems like unnecessary overhead for what would be a very commonly used idiom.
How many places in existing code can you find where eliding all but the first argument (or all but several arguments) would be useful?
@ianlancetaylor that's a fine point. Impossible to implement is justification enough for me. Though it would be possible to implement in some cases, where
Another option, that I'm fairly sure is a bad idea, would be to allow "keyed returns" to work in conjunction with named returns, by analogy with keyed struct literals:
though that would interact poorly with the semantics of the naked return. If
This was referenced
Aug 3, 2017
Counter-proposal that has been suggested elsewhere in the past (#19642). Allow
E.g. given the function signature
I think the example was given simply to provide a one of each function signature that is useful as a showcase. While not likely to see so many return values in real world code, returning the zero value of a struct using
My argument is that the primary benefit of the succinct syntax is that it improves the readability. If it makes it easier to type that's just a bonus.
If you see
You don't need to double check for things that are suspiciously close to a zero value like
It's immediately obvious that the only relevant value is
can be pattern matched by your brain as a unit without having to actually inspect anything. I'm sure we all do that now with similar blocks that contain one or more zero value-like expression. It's bitten me once or twice when I was debugging and my eye glazed over something that looked too close to a zero value making it hard to spot the obvious problem (I of course do not admit publicly to being the person who shadowed nil . . .).
I'm fine with how it is, however. This is just a potential way to make it a little bit easier.
@mewmew yes this proposal is based on a comment from that proposal (see the History section). I don't particularly see the point of the generic zero value except in the case of returns. It would solve the same problem, of course.
(I would like to be able to use
@davecheney sometimes it's not the number of return values, it's their struct-ness. Typing
That said, this particular proposal is not the only way to sooth that chore, as the OP noted.