Proposal

Add a tiny errors.Has function to make the errors.As mechanism ergonomically available in if statements.

errors.As is an essential function in the error-wrapping world we live in. But sometimes the caller is only interested in the type of the target, not its value. In that situation, errors.As is awkward to use in conditionals.

Implementation

Add a function errors.Has:

// Has returns true if err, or an error in its error tree, matches error type E.
// An error is considered a match by the rules of [errors.As].
func Has[E error](err error) bool {
  return errors.As(err, new(E))
}

A quick GH search reveals many candidate usages. Here's one example:

  err = container.RunExec(ctx, s.dockerCli, target.ID, exec)
  var sterr cli.StatusError
  if errors.As(err, &sterr) {
    return sterr.StatusCode, nil
  }
  return 0, err

This could be rewritten to:

  err = container.RunExec(ctx, s.dockerCli, target.ID, exec)
  if errors.Has[*cli.StatusError](err) {
    return sterr.StatusCode, nil
  }
  return 0, err

For

• It's a trivial addition, and makes it explicit that you're only interested in the type, not the value, so it adds to the clarity of the code.
• The errors.As(err, new(E)) construct obviously isn't widely known; errors.Has is discoverable.

Against

• We could instead just document the errors.As(err, new(E)) construct in the errors.As documentation.

Naming

Obviously errors.Has is similar to errors.As. Maybe that'll cause confusion? Although, it didn't stop errors.As and errors.Is.

That said, a name like errors.HasType is more explicit. But I absolutely hate it in comparison to errors.Has. I think the "typey" intent of the function is already made obvious by the type parameter. And when I see As, Is and Has together, is it not the missing triplet separated at birth?