reflect: add TypeAssert

[dsnet]

Consider the following benchmark:

func Benchmark(b *testing.B) {
	v := reflect.ValueOf(new(time.Time)).Elem()
	b.ReportAllocs()
	for i := 0; i < b.N; i++ {
		_ = v.Interface().(time.Time)
	}
}

This currently prints:

Benchmark-24    	37673833	        29.74 ns/op	      24 B/op	       1 allocs/op

Since the underlying time.Time is addressable, the Interface method must make a copy of it.

However, one primary reason to use the Interface method is to then assert it to a particular concrete type.

I propose the addition of:

// AssertTo is semantically equivalent to:
//    v2, ok := v.Interface().(T)
func AssertTo[T any](v reflect.Value) (T, bool)

which avoids the allocation since the value is never boxed in an interface.

Usage would then look like:

t, ok := reflect.AssertTo[time.Time](v)

and naturally matches type-assertion construct in the Go language itself.

---

Ideally, this would be a method on Value, but we don't have #49085.
If we did, the signature would be:

func (Value) AssertTo[T any]() (T, bool)

and usage would be more natural as:

t, ok := v.AssertTo[time.Time]()

[dsnet]

#57060 is a compiler optimization that may obviate the need for this API as this falls under the "short-lived heap allocated value" problem.

[dsnet]

Empirical evidence based on module proxy data on 2023-07-01:

• ~560k calls to Interface() (not all may be reflect.Value.Interface method calls)
• ~217k are immediately asserted to a single type (e.g., ... := v.Interface().(T))
• ~8k are immediately used in a type-switch (e.g., switch ... := v.Interface().(type) { ... })

This means at least ~40% usages of the Interface method could directly benefit from this API.

[dsnet]

As a performance workaround, you could do the following today:

func AssertTo[T any](rv reflect.Value) (v T, ok bool) {
    if v.CanAddr() {
        v, ok = *v.Addr().Interface().(*T)
    } else {
        v, ok = v.Interface().(T)
    }
    return v, ok
}

It's gross, but works.

[neild]

Bikeshed: reflect.ValueAs seems clearer to me.

[dsnet]

I like ValueAs more for readability, but also choose AssertTo to match the terminology of the language.

[mvdan]

@ianlancetaylor could I gently nudge this proposal for consideration? It would very slightly help with the encoding/json/v2 work :)

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

Plain 'Assert' might be confusing with C-style asserts. Should we call it TypeAssert? With the Type prefix we may not need the To suffix either.

t, ok := reflect.TypeAssert[time.Time](v)

I think this reads better than TypeAssertTo.