proposal: Go2: introduce check keyword for errors on LHS of assignment

[smasher164]

• Would you consider yourself a novice, intermediate, or experienced Go programmer?
  Experienced

• What other languages do you have experience with?
  C, C++, Assembly, Java, Python, Javascript, SML, Rust, Racket, Shell, SQL, LATEX.

• Would this change make Go easier or harder to learn, and why?
  It would make Go harder to learn, since it is one more choice the user must make before handling an error. Hopefully though, it becomes the default. It is also the first instance of an identifier being a keyword only in certain contexts. This could be confusing in cases where forgetting to bind check to a variable turns it into a variable.

• Has this idea, or one like it, been proposed before?
  The proposal that comes closest to this idea is proposal: Go 2: allow to mark assigments of errors to return immediately when non-nil or to call a handler function #42318. Other similar issues are Proposal: Go 2: error handling by assignment, with named handlers #32500 proposal: Go 2: operator to cause early function return on error #32601 Proposal: Go2: try: Change try() proposal to use a special character in the position where an error is returned #32884 proposal: Go 2: use symbol or function call in assignment for error handling #33150.

• If so, how does this proposal differ?
  1. proposal: Go 2: allow to mark assigments of errors to return immediately when non-nil or to call a handler function #42318 uses a special character to mark the variable, whereas this proposal uses a new keyword.
  2. proposal: Go 2: allow to mark assigments of errors to return immediately when non-nil or to call a handler function #42318 returns the zero value for unannotated variables, whereas this proposal relies on named return values to do the heavy lifting.
  3. proposal: Go 2: allow to mark assigments of errors to return immediately when non-nil or to call a handler function #42318 allows substituting a handler function for the annotation, whereas this proposal makes use of defer for handlers.
  4. Proposal: Go 2: error handling by assignment, with named handlers #32500 is far too broad in that it suggests panics, returns, and special operators, but doesn't specify evaluation order.
  5. Proposal: Go2: try: Change try() proposal to use a special character in the position where an error is returned #32884, proposal: Go 2: operator to cause early function return on error #32601, and proposal: Go 2: use symbol or function call in assignment for error handling #33150 do not assign an identifier to the variable on the left-hand side, and don't specify how that variable is mapped to the return value, leaving us to assume that it relies on some convention around the last return value being an error. They also use an operator instead of a keyword, which obscures the early exit that can happen.
  6. proposal: Go 2: use symbol or function call in assignment for error handling #33150 introduces a separate mechanism for wrapping an error.

• Who does this proposal help, and why?
  1. It helps authors of Go source code avoid three extra lines of code in the common case where they early exit on an error.
  2. It helps readers of Go source code follow a function's core logic more easily, by collapsing the gap between two successive lines of logic.
  3. Preserves the imperative style of Go source code. Unlike the try proposal, this proposal can't be abused to favor function composition.

• What is the proposed change?
  1. A new keyword check is introduced.
  2. The keyword is only valid on the left-hand-side of an assignment or short variable declaration.
  3. The keyword is only valid if it precedes an identifier that refers to a variable of type error.
  4. The keyword can only be used in a function that has named return values.
  5. In all other cases, check is a normal identifier. This keeps the change backwards-compatible to Go1.
  6. Given a function like this:

  func foo() (v1 T, err error) {
    x, check err := f()
  }
  

  is equivalent to the following code:

  func foo() (v1 T, err error) {
    x, err := f()
    if err != nil {
      return v1, err
    }
  }
  

• Is this change backward compatible?
  Yes

• Show example code before and after the change.
  Before

  func printSum(a, b string) error {
  	x, err := strconv.Atoi(a)
  	if err != nil {
  		return err
  	}
  	y, err := strconv.Atoi(b)
  	if err != nil {
  		return err
  	}
  	fmt.Println("result:", x + y)
  	return nil
  }
  

  After (normal return) https://play.golang.org/p/nYugCFk4o-Z

  func printSum(a, b string) (err error) {
  	x, check err := strconv.Atoi(a)
  	y, check err := strconv.Atoi(b)
  	fmt.Println("result:", x + y)
  	return nil
  }
  

  After (return with additional context) https://play.golang.org/p/zaTO6KjUXmF

  func printSum(a, b string) (err error) {
  	defer func() {
  		if err != nil {
  			err = fmt.Errorf("printSum: %w", err)
  		}
  	}()
  	x, check err := strconv.Atoi(a)
  	y, check err := strconv.Atoi(b)
  	fmt.Println("result:", x + y)
  	return nil
  }
  

  After (with a hypothetical error wrapper) https://play.golang.org/p/LQCn_Nj_I4C

  func printSum(a, b string) (err error) {
  	defer errors.Wrap(&err, "printSum")
  	x, check err := strconv.Atoi(a)
  	y, check err := strconv.Atoi(b)
  	fmt.Println("result:", x + y)
  	return nil
  }
  

• What is the cost of this proposal? (Every language change has a cost).

  • How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
    As long as they upgrade to the latest libraries for parsing/type-checking packages, most of their static analyses should be unaffected. I'm unsure if there are outliers that check for weird properties on the LHS of an assignment, or if their error handling analyses that would trigger false positives because they expect if err != nil.
  • What is the compile time cost?
    Time-complexity-wise the same. Can be implemented entirely in the frontend.
  • What is the run time cost?
    Nothing

• Can you describe a possible implementation?
  I have a partial implementation on https://github.com/smasher164/check-go. I haven't had time to finish changes to the typechecker, so all it does right now is tokenize and parse the check keyword on the LHS of an assignment.

• Does this affect error handling?
  Yes

• Why are named return values necessary?
  When annotating the error result, the natural question to ask is "what happens when the error is non-nil?"

  • Some proposals argue that we return zero values for everything except the error value, but that forces us to adopt the convention that there is only a single error value returned as the last. If we went this route, then named return values aren't necessary, but we would be enforcing a convention.
  • We could do a naked return, and was my original plan. But the assignment would fail in a nested scope where the err variable is shadowed. If we went this route, then named return values are still necessary, since they permit the naked return.
  • We could return the values of the currently shadowed names for the named return values. This permits the user to redeclare err in a new scope. This is the approach I preferred, since it provides the most flexibility around where the assignment can happen.

Edit:

1. I have relaxed the requirement on excluding underscores in named return values. We can simply return the zero value of that type when there's an underscore.
2. Referenced other similar issues.
3. Added playground links for the "After" examples.
4. Explain why named return values are necessary.
5. Mention that check being a context-dependent keyword is different from the way identifiers work today, and could potentially be confusing to work with.

[earthboundkid]

This seems substantively the same as the last check proposal, except on the LHS instead of a magic expression on RHS. The reason the last proposal was rejected AFAICT was that it turned out that check messed up code coverage percentages deeply (ie a line will count as covered even with no testing of error handling!), and no one wanted to bite that bullet. This proposal is not sufficiently different to get past that limitation, so I don't think it has much chance of being accepted.

[smasher164]

@carlmjohnson If line coverage is a blocker for error handling proposals, then I think it's fundamentally impossible for a language change that simultaneously removes the error handling boilerplate while making independent lines show up in a coverage report.

That being said, I'm sympathetic to the idea that coverage tools should show if an error path is exercised. Any coverage tool/instrumentation/report would have to accommodate operations within a single line (or at least special-case the check).

---

Also when you refer to the previous check proposal, do you mean the check/handle one, or the try one? Unlike either of those, this proposal does not rely on a handler block and keeps the imperative style by annotating the LHS. It eliminates ambiguity around what happens when invoking a function that doesn't return an error as its last parameter.

func f() (error, error, int)

func g() (i int) {
    check e1, check e2, v := f()
    return v
}

desugars into

func g() (i int) {
    e1, e2, v := f()
    if e1 != nil {
        return i
    }
    if e2 != nil {
        return i
    }
    return v
}

[smasher164]

@gptankit Feel free to draft a separate proposal for that idea, but it has been brought up before: #33233

Defining built-in function carries the risks that it looks like a regular function call. Inspecting code that redefines returnOnError would make it unclear that it's changing control flow.

One of the consequences behind this proposal is that an editor can highlight the check keyword differently, signifying during an assignment that something different is going on.

[ianlancetaylor]

This seems similar to #32500 #32601 #32884 #33150.

[ianlancetaylor]

I don't understand why this requires named result variables.

Purely as a matter of style, the new use of check seems to emphasize the error result, which tends to obscure the more important non-error code.

[ibudisteanu]

Hopefully the golang team will consider for an automatic error check. Something like in rust because

if err = call() { 
return 
}

is about 15% of the code I am working on.

By rough numbers we have:

if err = ... 583 occurrences
if err := ... 176 occurances

multiplied by 3 lines of code it means 2277 LOC just to treat the errors with the same exact error handling pattern.
The entire source code is 16095 LOC. The error handling is 14.14%

[ianlancetaylor]

@ibudisteanu This has been discussed at great length elsewhere. A good starting point is #40432. Let's keep discussion on this issue focused on this specific proposal. Thanks.

[smasher164]

@ianlancetaylor

This seems similar to #32500 #32601 #32884 #33150.

I can update my proposal to mention these. However,

• Proposal: Go 2: error handling by assignment, with named handlers #32500 is far too broad in that it suggests panics, returns, and special operators, but doesn't specify evaluation order.
• Proposal: Go2: try: Change try() proposal to use a special character in the position where an error is returned #32884, proposal: Go 2: operator to cause early function return on error #32601, and proposal: Go 2: use symbol or function call in assignment for error handling #33150 do not assign an identifier to the variable on the left-hand side, and don't specify how that variable is mapped to the return value, leaving us to assume that it relies on some convention around the last return value being an error. They also use an operator instead of a keyword, which obscures the early exit that can happen.
• proposal: Go 2: use symbol or function call in assignment for error handling #33150 introduces a separate mechanism for wrapping an error.

---

I don't understand why this requires named result variables.

I should have explained this more in the original proposal, but when annotating the error result, the natural question to ask is "what happens when the error is non-nil?"

1. Some proposals argue that we return zero values for everything except the error value, but that forces us to adopt the convention that there is only a single error value returned as the last. If we went this route, then named return values aren't necessary, but we would be enforcing a convention.
2. We could do a naked return, and was my original plan. But the assignment would fail in a nested scope where the err variable is shadowed. If we went this route, then named return values are still necessary, since they permit the naked return.
3. We could return the values of the currently shadowed names for the named return values. This permits the user to redeclare err in a new scope. This is the approach I preferred, since it provides the most flexibility around where the assignment can happen.

Purely as a matter of style, the new use of check seems to emphasize the error result, which tends to obscure the more important non-error code.

Edit: This is a tradeoff made for readability. Anything less than a keyword, and the code might be too cryptic because the function exits early.

[sergiokessler]

Purely as a matter of style, the new use of check seems to emphasize the error result, which tends to obscure the more important non-error code.

if you look at the code:

func printSum(a, b string) error {
	x, err := strconv.Atoi(a)
	if err != nil {
		return err
	}
	y, err := strconv.Atoi(b)
	if err != nil {
		return err
	}
	fmt.Println("result:", x + y)
	return nil
}

the error handling code tends to obscure the more important non-error code.

[qingtao]

I think better error-handling

expr? // return if err