proposal: Go 2: just return the error

[gregwebs]

Author background

• 5 years experience writing production Go code. I have forked and created Go error handling libraries.
• Other language experience: Many of the common languages that are not JVM/CLR (Rust, Haskell, Python, Ruby, TypeScript, SQL, bash, etc)
• I have opened other error handling proposals and reviewed many of the existing proposals- this experience has led me to realize that we really just need to fix how returning errors also requires returning zero values.

Related proposals

• This proposal is about error handling
• There is a very similar proposal to this that is still open. This proposal does not introduce a new syntax but instead relaxes the requirements for multiple return parameters when returning an error.

Proposal

When returning an error, one may omit the rest of the return values.

// before
return mystruct{}, package.PackageStruct{}, err

// after
return err

This new form matches the intent that "I just want to return an error".
The new form is optimal to read, write, and diff for the purpose of returning an error.

This form is allowed if and only if the last return value satisfies the interface error.
The value of the omitted return values will be the zero value of their type.

Motivation

The benefits to readability will be seen in every multi-valued error return statement, which is a significant amount of existing Go code.
I see Go programmers returning structs as pointers because nil is easier than hassling with putting empty structs at every return, so unfortunately the existing situation contributes to making the code messier outside just the return statement.

Reading, writing, diffing

• Reading: Existing code obscures the intent when reading- the reader needs to check that all the non-error values are in fact zeros and then ignore them.
• Writing: Writing out zero values is tedious but can be automated or atleast auto-completed by IDEs.
• Diffing: Diffs can be unnecessarily large- if I make a one line change at the bottom of my function to return one additional result, the only additional change the reviewer needs to see is the diff of the type signature. But the diff will also show adding zero values on all the rest of the return lines.

Orthogonality

This proposal could be viewed as an extension/specialization to the existing concept of a naked/bare error return.
Because of this, it may be best to use named return variables when they exist rather than only returning zero values.

This feature is specialized to errors. It is possible to attempt to generalize this feature to support using it to return any return result type that is uniquely typed. However, such a generalization is rarely useful outside of bare/naked returns and bare/naked returns are not used with high frequency in the Go community.

Compatibility

Old code will continue to compile on newer versions of Go.
New code will not compile on older versions of Go unless this feature is back-ported to older releases, or the new code is modified with automated tooling.

Costs

• What is the cost of this proposal? (Every language change has a cost).
  An additional rule to understand. Outside of the interaction with named results, this rule should be intuitive.

• Would this change make Go easier or harder to learn, and why?
  Some will argue this makes Go harder to learn because it is a new additional feature. I would argue it will make it much easier to learn Go because it will be significantly easier to read error return statements- that saved time will make it possible to spend more time learning Go.

• How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
  Most linters that use the Go analysis library could continue to work without change for most of their lints.
  However, some lints focused on the specifics of returns would require changes. It will now be easier to perform autofixes or suggestions that add an error return- these no longer need to bother with zero values.

• What is the compile time cost?
  Probably none? In theory an integrated compiler could compile this (probably not noticeably) faster since there is less to parse and returns must be type-checked already.
  However, the separation of compilation phases might mean the effect would be the opposite.

• What is the run time cost?
  None, in theory this might make some optimizations easier.

• Can you describe a possible implementation?
  No, but I imagine the machinery for this is probably somewhat in place already due to the existence of bare/naked returns.

• Do you have a prototype? (This is not required.)
  I have a library that panics (and recovers) an error. This achieves the same result of omitting zero values.

[andig]

You can‘t beat that for simplicity. It does not feel right though to make err special here, given that it is just another return parameter with no formal significance.

[gregwebs]

@andig thanks for voicing that concern. I guess there is a point of view that Go is just returning multiple values, and there is no reason to formalize the return of errors in any way.

The point of view that I am representing is that the code is not actually trying to return multiple values. The code is trying to return a success or an error, exclusively. Some functions are exceptions to this general pattern, and those exceptions should not use this feature, but what is described here represents the majority of functions in some code bases.

AFAICT this can only really only be generalized to actually adding a Result types to Go (or more generally a sum type), which would be an enormous challenge. This proposal describes the one reliable convention for using sum types in Go. The benefits of sum types are clear to anyone that has experience using them, but it is not actually clear that a Result type would produce easier to read code for this common pattern than what Go would have after this proposal.

[gregwebs]

In Zig a function can just return an error (or a success). The result type is formalized with ! as syntax in the type signature indicating that the function returns an error and there are also tools on the caller side for early return or pattern matching the error.

pub fn parseU64(buf: []const u8, radix: u8) !u64 {

The ! return result approach would work quite well in Go, but it's a more dramatic syntax addition. We could avoid adding a real result type for now and ! could be added such that it effectively compiles down to the current state of affairs where the right-most value is an error. But crucially this new ! syntax would allow for what is contained in this proposal. Additionally, when returning a success, one would omit the error rather than return nil.

The return type would ideally be a concrete error set as in Zig rather than erased into an error. It's currently very problematic in Go to return a concrete error due to the boxed dynamic type behavior: a nil concrete error type is not equal to a nil error (but these invalid comparisons will still compile). This behavior could be fixed for errors when using !.

[DeedleFake]

The point of view that I am representing is that the code is not actually trying to return multiple values. The code is trying to return a success or an error, exclusively. Some functions are exceptions to this general pattern, and those exceptions should not use this feature, but what is described here represents the majority of functions in some code bases.

An argument could even be made that standardizing the use of a result type for the usual case of value or error will signal to the client that a function that isn't using the result type might need some special handling. It may be too late for that benefit, though, since the standard library is filled with multi-return value-or-error functions already. Still, I'd personally really like to have functionality similar to the following available, though it would be dependent on #56462 or something similar:

type Result[T ...any] struct {
  v T
  err error
}

// Just doing some bikeshedding...
func R[T ...any](v T, err error) Result[T] { /* Converts from an existing multi-return function. */ }
func Success[T ...any](v T) Result[T] { /* Straightforward. */ }
func Err[T ...any](err string) Result[T] { /* Equivalent to errors.New(). */ }
func (r Result[T]) Must() T { /* Panic if there's an error. */ }
func (r Result[T]) IgnoreErr() T { /* Just return the value. */ }
func (r Result[T]) Or(v T) T { /* Return v if the error wasn't nil. */ }
func (r Result[T]) Err() error { /* Return the error, whether or not it's nil. */ }
func (r Result[T]) Unwrap() (T, error) { /* Return everything. */ }

// Elsewhere:
package fmt

func Resultf[T ...any](format string, args ...interface{}) { /* ... */ }

Unfortunately, the Err() and fmt.Resultf() constructors would be significantly less useful without some extensions to the generic type inference system. As it stands currently, you'd have to do something like return fmt.Resultf[time.Time]("parse time: %w", err), which would be annoying.

@gregwebs

That would require such a major overhaul of the type system that it seems extremely infeasible to me to implement for use with a single feature. I think an actual result type is far more likely to happen at some point.

[gregwebs]

I like the idea of the Unwrap api that goes from a sum type to multi-value with zeroes- it's the way to preserve compatibility, although I would name it different given its existing usage for errors!

It's easy to come up with the return result and such an API but it is harder to explain how this will actually be better on the caller side than what exists today. Rust had to add ? for early returns to avoid lots of nesting from matching, etc.

[ianlancetaylor]

It's good to make the eliding of values explicit, to avoid unexpected behavior if the function results change.

Based on the discussion, and the emoji voting, and the similarity to #21182, closing as a dup of #21182.