The biggest issue I have with this proposal is that reading the code in naïve fashion comes up with the wrong answer for me; YMMV. The proposed form--

  foo ? { bar }

Maybe it's just because I originally come from C, where `foo ? bar : baz` meant "if foo then bar else baz", but the fact remains...

I feel like error handling in Go is divided between people who have been using the language for a long time, and those who are new to it. If you're used to exceptions, and languages with some kind of '?' operator, typing `if err != nil` all the time is probably excruciating. They seem to be the most vocal in the survey about wanting beloved error handling features from their favorite languages.

Once you've been using the language for awhile, you begin to dislike the elaborate system of rugs other languages have to sweep errors under. Errors in Go are right there, in your face, and undeniable that the operation you are doing can be faulty somehow. With good error wrapping, you can trace down exactly which of these `if err != nil` blocks generated the error without a stack trace. If it bothers you that much, you can always make a snippet / macro for it in your editor.

It saddens me tbat the default error handler is "return err", as opposed to something that appends context/stack trace.

We've converted a few scripts and webapps from Python to Go, and if one does default handling ("return err") the error logs became significantly less useful, compared to exception backtraces. Yes, there are ways around it, but most tutorials don't show them.

I vote no on this proposal.

Go error handling should remain simple, like the language.

These are all tools, just pick the one you like and stop trying to make them like others.

(I'm not a Go programmer)

I find this a bit odd. Isn't the idea of the primitive error handling that it is obvious and easy, as in "functions can return multiple results, a popular pattern is to return the good result and the error as two separate nullable values of which exactly one will be not null, so you can check if err == nil."?

If you go with fancy error handling anyway, how is this '?' better than returning a Result and do something like foo().getOr { return fmt.Errorf("Tja: %v", err) }

This is from Ian Lance Taylor, a major figure in the development of Go. Taylor was instrumental in bringing generics to the language, this proposal is worth taking seriously.

I overall like it and would prefer a world where Go had this spec implemented versus did not.

Criticism:

> Within the block a new variable err is implicitly declared, possibly shadowing other variables named err

Shadowing here is strange, and I would prefer a design where it did not shadow other variables named err, but rather threw a compiler error concerning the re-declaration of a variable. That would effectively mean that you can't mix-and-match this syntax with old error-handling inside one function, because code like this would fail to compile:

    func Test() {
      user, err := GetUser("12345")
      if err != nil {
        panic(err)
      }
      EmailUser(user) ? {
        panic(err)
      }
    }

This change would mark a turn in the language's evolution, as it would be the first implicit variable to be added to the language.

I'm not going to invoke the slippery slope argument, but what distinguishes Go from the pack is how explicit it is. It can make it more tedious to write, but also much easier to follow as a reader.

Unfortunately, every software project will eventually reach a point of maturity where more and more features are added simply for the sake of adding them.

"The goal of this proposal is to introduce a new syntax that reduces the amount of code required to check errors in the normal case, without obscuring flow of control."

The key is "check errors in the normal case".

When the core principles of Go have always been simplicity, flexibility, and having one way of doing things, this feels completely like a step in the opposite direction. We will have syntax sugar for "normal cases" while still relying on the `if err != nil` block for everything else. It’s similar to how we now have both `iterators` and `for loops` as constructions for loops.

My knee jerk reaction is that introducing even more ways to write the same thing is going to slowly bloat the language, but Go does it infrequently enough that it doesn't seem like it's going to become a huge problem. I think I could get used to this syntax.

> Disadvantage 4: No other block in Go is optional. The semicolon insertion rule, and the fact that a block is permitted where a statement is permitted, means that inserting or removing a newline can convert one valid Go program into another. As far as I know, that is not true today.

Yeah, this seems like a big problem to me, personally. Go has a fair number of lingering foot guns but this is one too far IMO. I think the no-block case should require something else to follow it, perhaps the return keyword. That'd also help prevent it from being as easily missed...

I really hate that a bare ? makes us lose some info on code coverage. If you only test the happy path, the line is counted as covered. Making the return explicit at least makes it obvious when a line is uncovered.

But my biggest beef is the implicit variable declaration, I can’t stand it. That’s just lazy, bad design.

That’s not a great proposal overall, and I suspect if the same proposal had been made by someone else outside of the Go core team, we would have not heard of it.

I hope it gets rejected.

It is crazy that error handling is one of the most important things, yet even modern languages suck at it.

In my opinion everything should return type like MayFail<T>, Result<T>

The proposal confuses shadowing of err, which is mostly irrelevant anyway but at least you can see it today. It also makes breakpoints or inserting log statements etc. more difficult without reformatting code. And lastly, it teases the ternary conditional operator that Go lacks, constantly reminding me of this. So IMO I would use a different language rather than adopt this.

Error handling is really not an issue that needs fixing in Golang. That being said, I wish Golang had an assert key word as a shortcut to "if cond { panic }". A lot of those "if err != nil" in the wild should really just be assertions.

Seems like the author assumes that only one error is returned. What if I want to return []error? What happens if my return objects are out of the normal order? Like F() (int, error, int) {...}.

The proposal is nice, but a bit shallow.

If I may make a suggestion to @ianlancetaylor, I think using the ? for error checking is a fantastic idea, but I think a couple small changes would make this absolutely a game changer and even more Go-like:

To demonstrate my tweak to your idea, imagine this example code:

r, err := SomeFunction() if err != nil { return fmt.Errorf("something 1 failed: %v", err) }

r2, err := SomeFunction2() if err != nil { return fmt.Errorf("something 2 failed: %v", err) }

r3, err := SomeFunction3() if err != nil { return fmt.Errorf("something 3 failed: %v", err) }

In the current proposal it would turn into this:

r := SomeFunction() ? { return fmt.Errorf("something 1 failed: %v", err) }

r2 := SomeFunction2() ? { return fmt.Errorf("something 2 failed: %v", err) }

r3 := SomeFunction3() ? { return fmt.Errorf("something 3 failed: %v", err) }

My first suggestion is to keep `err` variables visible. It ends up being not much longer, but it is much more readable and Go-like:

r, err := SomeFunction() ? { return fmt.Errorf("something 1 failed: %v", err) }

r2, err := SomeFunction2() ? { return fmt.Errorf("something 2 failed: %v", err) }

r3, err := SomeFunction3() ? { return fmt.Errorf("something 3 failed: %v", err) }

My second suggestion is to require ? to always have a block, and also allow them to "chain" so only the last statement needs a block:

r, err := SomeFunction() ? r2, err := SomeFunction2() ? r3, err := SomeFunction3() ? { return fmt.Errorf("something 1, 2 or 3 failed: %v", err) }

As you can see this is much shorter! Having the block is always required at the end of the "chain" of question mark statements is more consistent with how `if` statements require a block currently. It also makes the `return err` flow also always visible (no return magic). It also also has a huge advantage of it being much harder to miss a question mark syntactically. as a question mark without a block would be a syntax error.

For example, this is an error:

r, err := SomeFunction() ? // <-- compile error: missing block after ?

And also this is an error:

r, err := SomeFunction() ? r2, err := SomeFunction2() // <-- compile error: missing block after ? r3, err := SomeFunction3() ? { return fmt.Errorf("something 1, 2 or 3 failed: %v", err) }

Thanks for listening! Curious what folks think.

honestly with copilot and friends this is not really an issue

This breaks go's readability and explicit nature. No thanks. The author doesn't understand the implications of the proposal. What if the args are in a different order returned? "foo, error" or "error, *foo" ? - I've seen many permutations of this. Being explicit about error handling is actually a good thing.

5 years ago I would be more sympathetic to this proposal.

But now we have LLM copilots, so writing boilerplate in any language is dramatically more optional.

And I don't see this proposal significantly improving readability of the code.