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

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.

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.

Bikeshed: reflect.ValueAs seems clearer to me.

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

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

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

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.

Have all remaining concerns about this proposal been addressed?

The proposal is to add to package reflect:

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

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

The proposal is to add to package reflect:

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

How about also adding

func TypeAssertInto[T any](v reflect.Value, t *T) bool

So that sometimes, we can use

var x string
...
if reflect.TypeAssertInto(v, &x) {...}

instead of

var x string
...
x, ok := reflect.TypeAssert[string](v)
if ok {...}

Both of the two functions have their own ideal use cases.

Let's start with just one.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

The proposal is to add to package reflect:

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

Change https://go.dev/cl/591495 mentions this issue: reflect: add TypeAssert

The CL for this got abandoned. @dsnet did you want to get it in before the freeze?

@dsnet I have only just realized that you self-assigned this issue, but as i already have a working implementation, decided to send a CL for it. CL 648056

Change https://go.dev/cl/648056 mentions this issue: reflect: add TypeAssert[T]

While looking at the diff i realized that, TypeAssert is documented as semantically equivalent to: v2, ok := v.Interface().(T)

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

Do we really want that? Consider:

func TestTypeAssert2(t *testing.T) {
	val := ValueOf(&net.DNSError{})
	_, ok := TypeAssert[error](val)
	t.Log(ok) // false
	_, ok = val.Interface().(error)
	t.Log(ok) // true
}

The implementation in CL 648056 returns false, true, but based on the docs it should return 2xtrue.

The goal is for the reflect package to more or less duplicate the language. Since the language permits type assertions to interface types, I would expect reflect.TypeAssert to do the same. I think we would need a special argument for any other behavior, and I don't see that argument in this proposal.

Is there a good reason that we shouldn't implement the language behavior?

@mateusz834, no worries. I had a local CL for this that I was gonna send out after the freeze. I don't mind going with your CL so long as it's fast for concrete types and I get to use it in Go 1.25 😄.

TypeAssert is documented as semantically equivalent to: v2, ok := v.Interface().(T) ... Do we really want that?

When I implemented this myself, I noticed this difference as well. Implementation-wise, it seems easier to violate the documented behavior, but on the other hand, it's very easy to explain TypeAssert being equivalent to v2, ok := v.Interface().(T).

My approach (CL/648235) only special cases concrete types and delegates the handling of interfaces to v.Interface().(T).

Change https://go.dev/cl/648235 mentions this issue: reflect: add TypeAssert

There is also this kind of behavior in the Interface() logic:

func newPtr[T any](t T) *T {
	return &t
}

func TestTypeAssert2(t *testing.T) {
	val := reflect.ValueOf(newPtr(any(1))).Elem()
	_, ok := val.Interface().(int)
	t.Log(ok) // true

	val = reflect.ValueOf(newPtr(error(&net.DNSError{}))).Elem()
	_, ok = val.Interface().(*net.DNSError)
	t.Log(ok) // true
}

I don't know whether TypeAssert should follow it, it had to be this way for Interface(), because of how interfaces work, but for TypeAssert we don't have to do this kind of logic.

EDIT: It makes sense in terms of Interface().(T), but i wonder whether this is the expected behavior of a generic function. It might be tempting to use TypeAssert as a helper to check whether Value has the same type as T and to extract the value of it. If we make it the same as Interface().(T), then it still requires the use of reflect.TypeFor[T]() == val to check whether this is the type we expect, but because it is generic it might be easy to miss that.