Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go 2: new syntax for abbreviation of if err != nil { return ..., err } #51146

Closed
lance6716 opened this issue Feb 11, 2022 · 3 comments
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal v2 An incompatible library change
Milestone

Comments

@lance6716
Copy link

lance6716 commented Feb 11, 2022

Author background

  • Would you consider yourself a novice, intermediate, or experienced Go programmer?
    experienced
  • What other languages do you have experience with?

Related proposals

Proposal

  • What is the proposed change?
    One line introduce: Go will expand some Function()? to equivalent if err != nil { return ..., err }

    An example from my demo https://github.com/lance6716/errhell

func manyReturn() (
	complex64,
	*int,
	<-chan struct{},
	[]float32,
	interface{},
	func(error) error,
	map[string]interface{},
	error,
) {
	returnError()?
	return 0, nil, nil, nil, nil, nil, nil, nil
}

will be converted to

func manyReturn() (
	complex64,
	*int,
	<-chan struct{},
	[]float32,
	interface{},
	func(error) error,
	map[string]interface{},
	error,
) {
	_err0 := returnError()
	if _err0 != nil {
		return 0, nil, nil, nil, nil, nil, nil, _err0
	}
	return 0, nil, nil, nil, nil, nil, nil, nil
}
  • Who does this proposal help, and why?
    Developer can write less code 😄

  • Please describe as precisely as possible the change to the language.
    The new token ? can only be legal appended to such a function call, name it fn:

    • the fn has one or more return values, and only one return value implements error interface
    • the caller of the fn has no more than one return values which implements error interface

    If it's legal, the effect is equivalent to a if statement being inserted after the call of fn. The returned error of fn will be nil-checked, and there's a return statement in then-body to fill the return values of caller of fn with the error and/or zero values.

    I have made a demo: https://github.com/lance6716/errhell , the test input can be found in https://github.com/lance6716/errhell/blob/936cdcb459015fd5ce066b3f9b4325dcff6a8430/test/input/input.go and equivalent output can be found in https://github.com/lance6716/errhell/blob/936cdcb459015fd5ce066b3f9b4325dcff6a8430/test/expected/expected.go

  • What would change in the language spec?

  • Please also describe the change informally, as in a class teaching Go.
    I think my demo and example is clear to explain it.

  • Is this change backward compatible?
    No

    • Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit.
      Show example code before and after the change.
    • Before
    • After
  • Orthogonality: how does this change interact or overlap with existing features?
    No

  • Is the goal of this change a performance improvement?
    No

    • If so, what quantifiable improvement should we expect?
    • How would we measure it?

Costs

  • Would this change make Go easier or harder to learn, and why?
    No change if don't use it
  • What is the cost of this proposal? (Every language change has a cost).
    compiling is a bit more complex?
  • How many tools (such as vet, gopls, gofmt, goimports, etc.) would be affected?
    I'm not sure about how they work, but they should be able to re-use the syntax
  • What is the compile time cost?
    I'm not an expert 😢 But I think as my demo it only requires checking the current stack.
  • What is the run time cost?
    Only affects compiling
  • Can you describe a possible implementation?
    See my demo https://github.com/lance6716/errhell
  • Do you have a prototype? (This is not required.)
    https://github.com/lance6716/errhell
@gopherbot gopherbot added this to the Proposal milestone Feb 11, 2022
@seankhliao
Copy link
Member

@seankhliao seankhliao added error-handling Language & library change proposals that are about error handling. v2 An incompatible library change LanguageChange Suggested changes to the Go language labels Feb 11, 2022
@ianlancetaylor
Copy link
Contributor

Also similar to #21155.

As it says at #40432 these kinds of changes are typically rejected because they are cryptic: a single ? leads to a change in flow control.

@lance6716
Copy link
Author

nothing new under the sun 😂

@golang golang locked and limited conversation to collaborators Feb 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
error-handling Language & library change proposals that are about error handling. FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal v2 An incompatible library change
Projects
None yet
Development

No branches or pull requests

4 participants