[9rx]

> and it gives the same improved experience to the caller as your suggestion

Albeit a contrived suggestion for the sake of brevity. In the real world you are going to need to write something more like:

   first, err := getFirst()
   var err1 *fooError
   var err2 *barError
   switch {
   case errors.As(err, &err1):
      return nil, FirstError1{err1.Blah()}
   case errors.As(err, &err2):
      return nil, FirstError2{err2.Meh()}
   case errors.Is(err, io.EOF):
      return nil, EOF{}
   // ...
   case err != nil:
      return nil, FirstError{err}
   }

And that is where eyes start to gloss over. The trouble with errors is that they quickly explode exponentially. Programmers long to distill all possible errors into one logical operation to not have to actually think about all the cases, since that is hard and programmers are lazy, but that is not sufficient for a lot of programming problems.

The cutesy shortcuts like ? and % operators are fine for some classes of programming problems, to be sure, but there are numerous languages that are already designed for those classes of problems. Does Go even need to consider travelling into those spaces? In the original Go announcement it was made explicitly clear that it was designed for a very particular need and was never intended to be a general purpose programming language.

I'm certainly not the gatekeeper. If Go wants to move away from its roots and become the must-have language for the classes of problems where something like ? is a wonderful fit, so be it. But, from my point of view, putting energy into tackling the big problems is more interesting. There should be plenty of room for improvement in the above code without losing what it stands for. But that is going to require a lot more deep thought than I've seen put in and programmers are lazy, so...

[Dylan16807]

If you need different logic for different errors out of a function call you wouldn't use this, but your example code there... I think it's at the point where you've made things more complicated for your caller than just returning FirstError{err} no matter what the error is. The caller still has to deal with all the errors getFirst can cause, but they've been reorganized in a complicated bespoke way.

> Does Go even need to consider travelling into those spaces?

Oh come on. Changing how one common piece of boilerplate is written is not travelling into new spaces or moving away from Go's roots.