proposal: Go 2: permit using errors.Return, etc., on LHS of an error assignment

This approach has probably been discussed in the past. I like to make this a quick feedback.

Existing code:

bg, err := task.NewBackground()
If err != null {
…
}

If I could instantly identify different type of errors handling in a quick reading, it could be written with errors.### that are implements to receive strings, custom types, etc:

Radom ideas when return errors from .NewBackground() is not null:

bg, errors.Return := task.NewBackground()
bg, errors.Fatal := task.NewBackground()
bg, errors.Console := task.NewBackground()
bg, errors.Info := task.NewBackground()
bg, errors.Log := task.NewBackground()
bg, errors.CustomSentAlert := task.NewBackground()

Go runtime will handles according to each API.

Does this make sense for handling common errors? I could be wrong as to how these approach works or could be done on package.

[DeedleFake]

I'm sorry, but I don't understand what you are proposing. Are you suggesting essentially something like extension methods, but only for errors, that would be able to handle the error in place by being callable on the left-hand side of an assignment?

[ianlancetaylor]

For language change proposals, please fill out the template at https://go.googlesource.com/proposal/+/bd3ac287ccbebb2d12a386f1f1447876dd74b54d/go2-language-changes.md .

When you are done, please reply to the issue with @gopherbot please remove label WaitingForInfo.

Thanks!

I appreciate Ian for a better title.

I know Go is an opinionated language, apology in advance if the proposal does not look good or other folks have brought up, already my background experience is Mechatronics and working in IT industry and I have nothing else to add in this proposal.

• Would you consider yourself a novice, intermediate, or experienced Go programmer?
  Experience more than novice, ported form handling from Nodejs to Go.

• What other languages do you have experience with?
  PHP, NodeJS, Javascript, Swift (Server Side). A smidgen experience with other modern languages, Rosetta Code is an interesting part of my exploration into programming language.

• Would this change make Go easier or harder to learn, and why?
  Easier is subjective for some reader, we all have a common error checking, it’s certainly readable to pass any non-null errors from RHS to LHS, I’ve been thinking how to create csp-like pattern and probably without breaking backward compatibility.

You are less likely miss out handling an error, it happened to my case.

• Has this idea, or one like it, been proposed before?
Not that I know if it been proposed before.

• Who does this proposal help, and why?
  For anyone who used to concise syntax, this is a tiny feature, I see other have downvoted which is fine if the default approach is non-issue.

• Is this change backward compatible?

• Breaking the (Go 1 compatibility guarantee)[https://golang.org/doc/go1compat] is a large cost and requires a large benefit.
  It look compatible to Go 1.

• Show example code before and after the change.

// We does this all the time and useful for multiple line of code.
bg, err := task.background()
If err != null {
	fmt.Println(“The way to show errors”)
	// Other code
	return
}


// I seen someone used this approach
bg, err := task.background()
If err != null {
	 err = “The way to show errors”
}


// It easy to write this today, but I might forgot to write or accidentally remove info(err), will cause application crash.
bg, err := task.background()
info(err)

To

// Instantly interpret the types of error information it will produce, anything else to add? Nothing.
bg, errors.Info := task.background()

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

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

• What is the compile time cost?
  Less code to compile

• What is the run time cost?
  Not sure

• Can you describe a possible implementation?
  Nope

• Do you have a prototype? (This is not required.)
  Nope

• How would the language spec change?
  Not sure

• Orthogonality: how does this change interact or overlap with existing features?
  It does similar to common errors.

• Is the goal of this change a performance improvement?
  Not sure

• Does this affect error handling?
  Sure does, more friendlly to read.

• Is this about generics?
  Nope

@gopherbot please remove label WaitingForInfo

[ianlancetaylor]

We don't understand your example code. The after code doesn't seem to correspond to the before code.

We would need an exact and complete list of available options. Things like errors.Return and errors.Info seem very different: one affects control flow and the other does not. We don't know what errors.CustomSentAlert means. The example suggests that info somehow corresponds to errors.Info; how?

-- for @golang/proposal-review