proposal: spec: else statement in assign statements

[protiumx]

Author background

• 1 year experience writing production Go code.
• Other language experience: Python, Typescritpt, Rust, C#.

Related proposals

This proposal is about else statements in assign statements. It is exclusively borrowed from the let-else statement introduced in Rust RFC 3137, which is also based on Swift's guard statement.

I haven't been able to find a similar existing proposals. Please close if duplicated.

Proposal

The goal of this proposal is to introduce a guard to simplify some very common error-handling patterns we frequently encounter when writing Go code. A short-hand way to return errors has been proposed a few times already (See #56628, #32437, #56165). I believe the existing proposals don't match 100% Go's mission for simplicity, correctness and readability.

Although introducing this feature could go against R. Pike's comment Go does not try to be like the other languages (See https://go.dev/talks/2015/simplicity-is-complicated.slide#9) I think the benefit is hard to ignore.

Code examples:

// before
result, err := getUser()
if err != nil {
  return err
}

exp, ok := number.(uint64)
if !ok {
  return fmt.Errorf("not uint64")
}

// after
result, err := getUser() else {
  return err
}

exp, _ := number.(uint64) else {
  return fmt.Errorf("not uint64")
}

The new else statement in a variable statement is easy to read and understand. It allows the developer to write code and think of its immediate error handling by moving the failure case into the body of the assign expression itself.

Spec

Only the last value is evaluated as the else condition. The last value must implement the error interface or be type bool

ret1, ret2, err := test() else {
  return err
}

ret1, err1, err2 := test() else {
  // err2 is not nil
  return err2
}

func testA() (error, string)


err, s := testA() else { // Compilation error. `s` does not implement `error` interface
  return err
}

Variable scope works as expected. Variables are not scoped to the else block

ret, err := testA() else {
  return err
}

// reuse err
ret2, err := testB() else {
  return err
}
err = testC() else {
  return err
}

Only available in assign statements

// Invalid: no assign statement
testC() else {
  return err
}

Only valid for a single expression on the right hand of the assignment

a, b := testA(), testB() else { // invalid
...
}

It is possible to omit the last returned value in type assertions and map access (as it is already possible)

exp := number.(uint64) else {
  return fmt.Errorf("not uint64")
}

m := map[string]string{}
value := m["value"] else {
  return fmt.Errorf("value not found")
}

Motivation

Go's simplicity is great but that simplicity usually come with a cost of repetition, especially when talking about error handling.
Go does not support pointer to boolean conversion hence developers have to write the following block constantly

ret, err := some()
if err != nil {
  return err
}

Although, this can be easily solved with a code snippet, codebases tend to be saturated by

if err != nil {
  return err
}

statements.
The proposal avoids repetition of the if err != nil code. There is no nil to bool conversion as the else statement would internally evaluate err != nil as its condition.

Readability is maintained or improved if considered that error handling is now part of the assignment statement.

Please refer to Rust RFC 3137 for more details on its motivation as I believe Go developers would agree with them.

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 automated tooling will desugar it.

Costs

What is the cost of this proposal?

An additional rule to understand when assigning variables. Specifically the rule of evaluating only the last result returned by the right hand of the assign statement.

Would this change make Go easier or harder to learn, and why?

Go is already a very simple language to learn. The intention of this new assign expression could seem natural to understand.
The new expression is also intended to be optional and more of a syntax sugar.

How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?

Linters and formatters would require to be extended to support the new assign expression.

What is the compile time cost?

Probably none. Some compilation step could be affected but it depends on the implementation. A naive approach could imply a desugar step of the source code. Otherwise the cost would reside during parsing step, modification to the AssignStmt in Go's AST or a new type of expression would be required.

What is the run time cost?

None

Can you describe a possible implementation?

I imagine extending the AssingStmt with an Else statement field (similar to Else in IfStmt).
The evaluation of this Else statement should work as expected when finding a return statement.

[seankhliao]

Duplicate of #41908