As a spin-off of the discussion in #48971, I propose to have cmd/vet report diagnostics for printf verbs that don’t match every element of a type parameter’s type set.

For example, consider the following:

func F[P ~int](p P) {
  fmt.Printf("%s", p)  // int is in the type set of P, and does not match %s
}

func G[Q any](q Q) {
  fmt.Printf(“%d”, q)  // many types in the type set of Q do not match %d
}

In this example, the type set of P is all types with int underlying. There are types in that type set (such as int itself) that do not match the verb %s, so we would report a diagnostic – something like fmt.Printf format %s does not match type int in the underlying type set for P.

Similarly, the type set of Q is all types, and there are of course many types in this type set that do not match %d, so we would report something like fmt.Printf format %d does not match constraint type ‘any’.

In these examples we might have false positives: it could be the case that F is only ever instantiated with arguments implementing fmt.Stringer. It could be the case that G is only ever instantiated with integral types. By comparison, we explicitly do not report such diagnostics for most arguments of interface type:

// Whether any particular verb is valid depends on the argument.
// The user may have reasonable prior knowledge of the contents of the interface.

However, with the new interface syntax in Go 1.18, we are able to express restrictions on both the method set and underlying type of a type parameter. If arguments of type parameter type are being passed to a %d verb, we can prove that this is OK if the type set is restricted to integral underlying types. On the other hand, if the type set is not restricted to integral underlying types, it is highly likely that this is a user error. Specifically, it is more likely than in the case of interface types, because users could have specified structural restrictions on the type parameter.

There is precedent here. In the initial implementation of printf checks for %w, it was decided that all arguments must be convertible to error (including, for example, arguments of type interface{}). The rationale behind this is similar to above: the user is able to express an ‘implements’ relationship between interface types, and if they did not it is likely a user error. [see also #48931].

Generics will be used to add type safety to existing code that previously used interfaces. By flagging potentially incorrect printf verbs, we can help users identify potential runtime errors and add accurate type restrictions to their type parameter constraints.

I have prototyped this feature, and think it is do-able for 1.18, though producing great diagnostic messages might be a bit tricky. I think it’s OK if we wait for 1.19.

CC @timothy-king @neild @bcmills @mvdan