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