I'd like to propose adding methods that take advantage of generics to make the Must idiom more widely used across the ecosystem.

The text/template package has a Must method for example, which takes a *Template and an error. If the error is not nil, it panics. If the error is nil, the template is returned.

This enables a more readable form of parsing and using a template if you expect it to succeed, as in the example:

var t = template.Must(template.New("name").Parse("text"))

Because Parse returns (*Template, error), these are passed to Must, and if successful, the *Template is returned and stored as a var.

This is commonly done because templates are defined as constants in code or maybe loaded at init-time, and are expected to be parseable. If they're not, it's programmer error and not user error, and the code should panic.

This idiom can be made generic with a method that takes a T any and an error, and if successful, return the T, otherwise panic.

Based on template.Must:

func Must[T any](t T, err error) T {
  if err != nil {
    panic(err)
  }
  return t
}

I think this method makes sense in the log package, where it can call Fatal or Panic, and be called like so:

var t = log.Must(template.New("name").Parse("text"))

regexp has its own variation, MustCompile, which could be replaced with:

var re = log.Must(regexp.Compile(`^[a-z]+\[[0-9]+\]$`)

Being reusable, folks can plug their own (T, error)-returning methods into log.Must:

var u = log.Must(url.Parse("https://golang.org"))

var ref = log.Must(name.ParseReference("ghcr.io/foo/bar"))

(The impetus for name.MustParseReference)

Or more fancifully, purely for illustration:

func rollDice() (string, error) {
  n, m := rand.Intn(6), rand.Intn(6)
  if n == 0 && m == 0 {
    return "", errors.New("snake eyes!")
  }
  return fmt.Sprintf("%d", n+m), nil
}

func main() {
  log.Println("rolled:", log.Must(rollDice()))
}

Notes

• This doesn't allow for any additional message to be added by the programmer, since Must(string, T, error) can't be called like Must("uh oh", rollDice()).
• The same idiom couldn't be supported in *testing.T since T would have to take the type for t.Must to know what to return. Maybe there's a more clever way I'm not seeing though.

Open Questions

• Should it call log.Fatal or log.Panic? Just panic?

Alternatives

Things that must be true before a program can proceed are handled today with the ubiquitous if err != nil and (often) log.Fatal. If a package-level var should be populated by something that can fail but mustn't, this can be done with an init that log.Fatals. If there are many things that must parse, this can get verbose and error-prone to write repeatedly in an init block.