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

• 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 #42318. Other similar issues are #32500 #32601 #32884 #33150.

• If so, how does this proposal differ? 1. #42318 uses a special character to mark the variable, whereas this proposal uses a new keyword. 2. #42318 returns the zero value for unannotated variables, whereas this proposal relies on named return values to do the heavy lifting. 3. #42318 allows substituting a handler function for the annotation, whereas this proposal makes use of defer for handlers. 4. #32500 is far too broad in that it suggests panics, returns, and special operators, but doesn’t specify evaluation order. 5. #32884, #32601, and #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. #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.