proposal: Go 2: Error-Handling Paradigm with ?err Grammar Sugar

[shynome]

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

I think I am a intermediate Go programmer. I have write golang 3 years

What other languages do you have experience with?

• typescript (javascript)
• elixir
• ziglang
• fsharp

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

this change make Go harder to learn, it has added a hidden return

Has this idea, or one like it, been proposed before?

• https://gist.github.com/lldld/bf93ca94c24f172e95baf8c123427ace

If so, how does this proposal differ?

I make the err variable must is a defined variable, it make err handle easily and clearly

// the exists proposal
f, ! := os.Open()

// my proposal
var err error
f, ?err := os.Open()

// you also can do like this
var try error
defer func () {
  if try != nil {
    // do soomething when err is not nil
  }
}
f, ?try := os.Open()

Who does this proposal help, and why?

All Go programmer who want write less code.

// 34 char
f, err := os.Open()
if err != nil {
  return
}
// 16 char
f, ?err := os.Open()

What is the proposed change?

It has add a Grammar Sugar

Please describe as precisely as possible the change to the language.

What would change in the language spec?

it add a operator ?

Please also describe the change informally, as in a class teaching Go.

// this useuall code way
f, err := os.Open()
if err != nil {
  return
}

// before use this Grammar Sugar, you must define the err bind
var err error
// add the ? op to the err variable, it will check err whether is nil, if err is not nil will return early
f, ?err := os.Open()

Is this change backward compatible?

Yes, it keep backward compatible.

Show example code before and after the change.

var err error // err must define before use ?err
// before
f, err := os.Open()
if err != nil {
  return
}
// after
f, ?err := os.Open()

var testErr error
// before
err = testErr
if err != nil {
  return
}
// after
?err = testErr

// example 3
func f() (i int,err3 error) {
  f, ?err3 := os.Open()
  // is equal
  f, err3 := os.Open()
  if err3 != nil {
    return
  }

  // of cause you can wirte code without ?err style
  // it just a grammar sugar, you can stop use it or start use it anywhere and anytime
  f, err := os.Open()
  if err != nil {
    return 0, err
  }
}

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?

all tools would be affected, similar the change add generics support

What is the compile time cost?

a little compile time cost more than before

What is the run time cost?

no run time cost

Can you describe a possible implementation?

? is a help func with return line

? = func (err *error) func(pos ...int) func(vars ...any) {
  for _, i := range pos {
    if e := vars[i]; e != nil {
      *err = e
      break
    }
  }
  return vars
}
if err != nil {
  return
}

var err error
a1, ?err, a1, ?err, err3 := int, error, int, error, error
-->
var err error
a1, _, a2, _, err3 := ?(&err)(1,3)(int, error, int, error, error)
// the below code for return is auto added by compiler
if err != nil {
  return
}

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

Yes, I have wrote a transpiler shynome/err4

How would the language spec change?

it add a operator ?

Orthogonality: how does this change interact or overlap with existing features?

I don't know about this.

Is the goal of this change a performance improvement?

No, it is not.

Does this affect error handling?

yes, it is

If so, how does this differ from previous error handling proposals?

This proposal do not add another keyword, instead of it add ?err (err must be a defined error type), it is a Grammar Sugar, it will not break old code.
Grammar sugar is make program hard read, this sugar with a hidden return, but I think it is worth

Is this about generics?

No, it is not.

---

Updated: ?err move to left, it make things easily

[mvdan]

Please note that you should fill https://github.com/golang/proposal/blob/master/go2-language-changes.md when proposing a language change.

[shynome]

Hi, I have fill the lost info.
this good idea is from lainio/err2, but err2 use panic to return early, that has run time cost

[ianlancetaylor]

This seems a lot like #25273 and many others. See #40432 for more links.

[shynome]

I change some things, it may be read clearer and implement easier

Can you describe a possible implementation?

? is a help func with return line

? = func (err *error) func(pos ...int) func(vars ...any) {
  for _, i := range pos {
    if e := vars[i]; e != nil {
      *err = e
      break
    }
  }
  return vars
}
if err != nil {
  return
}

var err error
a1, ?err, a1, ?err, err3 := int, error, int, error, error
-->
var err error
a1, _, a2, _, err3 := ?(&err)(1,3)(int, error, int, error, error)
// the below code for return is auto added by compiler
if err != nil {
  return
}

[shynome]

I have wrote a transpiler shynome/err4, here is effect

source code

package main

import "errors"

func main() {
	var qTerr error
	var qTerr2 error
	_, _ = qTerr, qTerr2

	qTerr = errors.New("e")

	var e1, e2 error
	_, qTerr, qTerr2 = 7, e1, e2
}

after transpile with go run ./cmd/err4gen/ -f ./testdata/main.go

// Code generated github.com/shynome/err4 DO NOT EDIT
package main

import (
	"errors"
	"github.com/shynome/err4"
)

func main() {
	var qTerr error
	var qTerr2 error
	_, _ = qTerr, qTerr2

	_ = err4.Check(errors.New("e"))(&qTerr)
	if qTerr != nil {
		return
	}

	var e1, e2 error
	_, _, _ = err4.Check2(7, e1, e2)(nil, &qTerr, &qTerr2)
	if qTerr != nil {
		return
	}
	if qTerr2 != nil {
		return
	}
}

Writing golang is easy and happy

[shynome]

I found the err variable don't need predefined.
!err is better read than ?err.

err := errors.New()
// replace err with !err, we can get if err != nil {return}
!err := errors.New()
// -->
err := errors.New()
if err != nil {return} // only fit with named return, a limit 

//if you want do something with err, predefine it and do that in defer func
var err error
defer func(){ if err != nil {// do something here} }()
!err = errors.New()

I want to close this, it's too similar with old proposal, why the old similar proposal had be closed?
I feel this proposal is good even it has some limit, so I am waiting a reason let me close this ticket

[ianlancetaylor]

You may retract and close this proposal at any time.

I think it is very unlikely that we would adopt this proposal. It is similar to several other proposals that we have not adopted.