In an assignment statement (= or :=), when any LHS operand is surrounded by parenthesis, ...

https://play.golang.org/p/LenMQLQyIU

@cznic Yeah, it conflicts with the current syntax. There are a few ways to get around that:

1. Outer parentheses on LHS always mean "assign if nil". In the current language, they can always be removed anyway withou changing the meaning.
2. Use another syntax for "assign if nil" such as a different kind of parentheses or something else.

As I mentioned over on #21161, I personally would prefer to see any change to error handling make it just as easy to wrap an individual error with more information as it does to simply move the error along.

@ianlancetaylor As you can see in the proposal, the error is wrapped with contextual information at the end.

d, (err) := f3(b, c)
if err != nil {
    return nil, errors.Wrap(err, "failed")
}

Functions that return errors should (and usually do) provide contextual informatiom themselves. Therefore you don't need to return "failed on pkg.Func" because that info is provided by the error returned from pkg.Func itself. That's why it's possible to assign the same contextual information to almost all returned errors and thus not deal with them individually, but group them as the proposal suggests.

When higher contextual information granularity is needed, one just falls back to the old style. But, I think that in such cases it doesn't feel like a boilerplate, because you're doing different things with each error.

It would be nice if someone gave this a Go2 label.

what if we add a ? in the error variable

d, err? := f3(b, c)

and this is like if we had this code

if err != nil {
    d, err := f3(b, c)
    return nil, errors.Wrap(err, "failed")
}

This solution es pretty similar to the one that rust uses for error handling https://m4rw3r.github.io/rust-questionmark-operator

@mrkaspa I like the question mark as a replacement for the parenthesis. So I would write this:

a, b, err? := f1()
c, err? := f2(a)
d, err? := f3(b, c)
if err != nil {
    return nil, errors.Wrap(err, "failed")
}

That's pretty nice, probably even nicer than my original proposal.

However, I don't think that automatically returning on ? is a good idea, like Rust does it.

@faiface I think it is, because this is the problem that godevs have when the handle they need to do is to return the error, if they need to handle this in another way they can use only err and handle it with a custom if

I think the question mark is generally used with null/nil.
Java, C#, Swift, and other languages use the ? to denote optional/nullable/nilable variables, as well as for the null/nil coalesce operator.

What about if when I do this:

a, b, err? := f1()

expands to this:

if err != nil {
    return nil, errors.Wrap(err, "failed")
}

and I can force it to panic with this:

a, b, err! := f1()

expands to this:

if err != nil {
   panic(errors.Wrap(err, "failed"))
}

This will keep backward compatibility, and will mend all the pain points of error handling in go

@SCKelemen in those languages the ? goes on the type not in the variable

@mrkaspa
I really am against returning on the (...) or ? syntax. The reasons are:

1. It breaks the flow and can be hard to read.
2. Makes it hard to return customized error values.

Just to clarify, my proposal is to simply skip the assignments where variables marked with ? (or (...) in the original proposal) are not nil (or zero value in general).

Just to check my understanding, given this code:

var errF1 = errors.New("f1 error")

func f1() (string, error) {
  return "f1", errF1
}
func f3() {
  fmt.Println("f3")
}
// f2(), f4() purposely left out, they're implementations aren't important.

func run() error {
  _, (err) := f1()
  _, (err) := f2()
  f3() // f3() is always executed?
  _, (err) := f4()
  return err
}

run() would return errF1 and the code would print f3. Is that right?

@buchanae That's right!

@faiface
I like the idea, but the syntax has to be worked on.
What I dislike is the fact that condition and result is not clearly understandable.

Since go does not have a ternary operator, what about this:

a, b :=  err ? f1()

which could obviously be extended to

a, b :=  err ? f1() : fallbackA, fallbackB

The docs would be as clear as:

"The ternary operator in go differs from that in C in that the condition is a single variable which is implicitly checked for being a zero value".

Issue #21161 is a general discussion of error handling changes to the languages. Closing this issue in favor of that one.