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...

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.

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.

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 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) }

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)
      }
    }

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.

"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.

> 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...

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.

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

The proposal is nice, but a bit shallow.

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.

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.