Proposal Details

For library APIs which return an error and a value, it is commonplace to provide Must* variants of the corresponding function. The Must* variant usually wraps the non-Must function, panicking when an error is returned. Here is an example from the standard library:

package regexp

// Compile parses a regular expression...
func Compile(expr string) (*Regexp, error) {
    ...
}

// MustCompile is like [Compile] but panics if the expression cannot be parsed.
func MustCompile(str string) *Regexp {
    ...
}

With the introduction of generics, this pattern becomes unnecessary, since one can write a must function:

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

With this function, and the 'call shortcut', one can write:

must(regexp.Compile("[a-z]+")).FindString(input)

While one could always define this function in an external package, it only really becomes useful if it's just available by default. So here is the rationale for making it builtin:

• Similar to builtins min and max, the use of this function will likely become pervasive, especially in tests. See also cmp: new package with Ordered, Compare, Less; min, max as builtins #59488 (comment)
• If defined in an external package, it'd have to be defined as Must. Having to prefix every use of must with a package name really takes away from the appeal of the function, as does using it with an uppercase identifier. The call to must should not steal attention from the call of the inner function, just change the semantics of that call.
• Finally, defining it as a builtin would make it possible to support any number of return values (where the last type is error). This isn't possible in a user-defined function because they must always declare a specific number of parameters and return values.