reflect: add TypeFor

[josharian]

reflect.TypeOf is one of a few fundamental reflect APIs. It returns the dynamic type of a value. This is, strictly speaking, sufficient. However, it is non-obvious how to use it to get a static type. The correct code is long, awkward, and hard to explain.

Pre-generics, there was no way to write a nice API to get a static reflect.Type. Now there is.

// MakeType returns the reflection Type that represents the static type of T.
func MakeType[T any]() reflect.Type {
	return reflect.TypeOf((*T)(nil)).Elem()
}

I propose that we add it.

It is a single line implementation, but it fills an obvious gap in the package reflect API and makes call sites clear.

I strongly suspect that almost all uses would be in conjunction with reflect.Type.Implements. An alternative would be make a generic version of implements that accepts an interface type as a type parameter, but fundamental building blocks compose better.

EDIT: this originally proposed StaticTypeOf; renamed to MakeType, per discussion.

[earthboundkid]

Compare #50741

[rsc]

Gob uses tricks like

binaryMarshalerInterfaceType   = reflect.TypeOf((*encoding.BinaryMarshaler)(nil)).Elem()

and this would let us write

binaryMarshalerInterfaceType   = reflect.StaticTypeOf[encoding.BinaryMarshaler]()

which is definitely nicer. Static is probably not the right word - that's a C word with lots of overloaded meanings. But something with that behavior would help.

[DeedleFake]

I've wanted something like this on more than one occasion as well. There have been several talks about adding a nicer generic way to get a zero value of a type, something similar to nil but for any value. If one of those actually goes somewhere, let's say using _ as a value, then combining that with #50741 would let you do something like reflect.GenericTypeOf[int](_).

[earthboundkid]

Can someone do a corpus analysis to see what the relative frequencies of different reflect operations are (GenericTypeOf vs StaticTypeOf equivalents)?

[mvdan]

To bikeshed on shorter names: TypeOfT, TypeFrom.

[rogpeppe]

or even reflect.T ?

[earthboundkid]

A cursory look at just the standard library reveals dozens of places where reflect.T[whatever]() could be substituted in for greater clarity. reflect.GenericValueOf is harder to qualify because there are a few places where the interface type was clearly what was wanted, but in a lot of cases, the underlying concrete type is the target. Adding reflect.GenericValueOf will add a level of ambiguity when reading code: Does the author really want the interface type here or did they just see generics and assume this function is newer and therefore better? It adds a second way of doing things without being 100% clear about what's intended. So I'm leaning towards +1 on reflect.T but +0 on reflect.GenericValueOf.

[ianlancetaylor]

reflect.TypeOf is a good name. I hope I'm not missing anything, but it seems to me that the new proposed function will always return the same value as reflect.TypeOf except when passing an argument of interface type. So since we already have reflect.TypeOf, and it works fine, what we need is a function that returns that reflect.Type for an interface type. I suggest reflect.TypeOfInterface.

[mvdan]

@ianlancetaylor I'm not sure I agree; I would personally want to use the generic API consistently. There would be little reason to use a mix of both APIs if the new one is more than enough. Consistency is the same reason why I use reflect.TypeOf((*string)(nil)).Elem() instead of reflect.TypeOf(""), for example.

Put another way, I much prefer reflect.NewAPI[string] (whatever its name) over either of the existing options above.

[ianlancetaylor]

Thanks, that kind of makes this an instance of #48287. It's hard to think of a good name, since the right name is already taken.