proposal: reflect: add `Value.Unpack[T any]` for unpacking Values into Go types

[mateusz834]

EDIT: see #78007 (comment) for latest proposal

Proposal Details

In the reflect package we have two ways to convert a Value into a Go type, i.e. v.Interface.(T) and reflect.TypeAssert[T](v).

Both of these work on interface-basis, and are not easy to reason about (especially the TypeAssert, since the interface is "hidden" through generics), see the comments in the implementation, for all the corner-cases:

go/src/reflect/value.go

Lines 1535 to 1553 in b9545da

	// If v is an interface, return the element inside the interface.
	//
	// T is a concrete type and v is an interface. For example:
	//
	// var v any = int(1)
	// val := ValueOf(&v).Elem()
	// TypeAssert[int](val) == val.Interface().(int)
	//
	// T is a interface and v is a non-nil interface value. For example:
	//
	// var v any = &someError{}
	// val := ValueOf(&v).Elem()
	// TypeAssert[error](val) == val.Interface().(error)
	//
	// T is a interface and v is a nil interface value. For example:
	//
	// var v error = nil
	// val := ValueOf(&v).Elem()
	// TypeAssert[error](val) == val.Interface().(error)

go/src/reflect/value.go

Lines 1559 to 1562 in b9545da

	// If T is an interface and v is a concrete type. For example:
	//
	// TypeAssert[any](ValueOf(1)) == ValueOf(1).Interface().(any)
	// TypeAssert[error](ValueOf(&someError{})) == ValueOf(&someError{}).Interface().(error)

What we are missing is a way to convert a Value directly into a Go type without all these interface unpacking/packing logic.

I propose we add:

// As attempts to unpack v into type T.
// It returns the value and true if v.Type() == reflect.TypeFor[T](),
// otherwise the zero value of T and false.
//
// Panics if the Value was obtained by accessing
// unexported struct fields.
func (v Value) As[T any]() (val T, ok bool)

Implementation-wise, it would be identical to TypeAssert, but without the special cases

go/src/reflect/value.go

Lines 1535 to 1576 in b9545da

	// If v is an interface, return the element inside the interface.
	//
	// T is a concrete type and v is an interface. For example:
	//
	// var v any = int(1)
	// val := ValueOf(&v).Elem()
	// TypeAssert[int](val) == val.Interface().(int)
	//
	// T is a interface and v is a non-nil interface value. For example:
	//
	// var v any = &someError{}
	// val := ValueOf(&v).Elem()
	// TypeAssert[error](val) == val.Interface().(error)
	//
	// T is a interface and v is a nil interface value. For example:
	//
	// var v error = nil
	// val := ValueOf(&v).Elem()
	// TypeAssert[error](val) == val.Interface().(error)
	if v.kind() == Interface {
	v, ok := packIfaceValueIntoEmptyIface(v).(T)
	return v, ok
	}
	// If T is an interface and v is a concrete type. For example:
	//
	// TypeAssert[any](ValueOf(1)) == ValueOf(1).Interface().(any)
	// TypeAssert[error](ValueOf(&someError{})) == ValueOf(&someError{}).Interface().(error)
	if typ.Kind() == abi.Interface {
	// To avoid allocating memory, in case the type assertion fails,
	// first do the type assertion with a nil Data pointer.
	iface := *(*any)(unsafe.Pointer(&abi.EmptyInterface{Type: v.typ(), Data: nil}))
	if out, ok := iface.(T); ok {
	// Now populate the Data field properly, we update the Data ptr
	// directly to avoid an additional type asertion. We can re-use the
	// itab we already got from the runtime (through the previous type assertion).
	(*abi.CommonInterface)(unsafe.Pointer(&out)).Data = packEfaceData(v)
	return out, true
	}
	var zero T
	return zero, false
	}

Assumes #77273

[mateusz834]

The rationale here is that, although I implemented TypeAssert, I'm not sure how it should be used (or whether my uses of are correct in all corner cases) to detect and extract a value only (and always) when v.Type() == reflect.TypeFor[T]().

And I believe most people actually want As than TypeAssert, and it is easy to accidentally assume that TypeAssert would behave the same as As.

[gabyhelp]

Related Issues

• reflect: add TypeAssert #62121 (closed)
• proposal: reflect: add alloc-free way retrieve value from Value #46093 (closed)
• proposal: reflect: add generic variants of `TypeOf()` and `ValueOf()` #50741 (closed)
• proposal: errors: Add generic errors.As #53045 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[mateusz834]

#46093 (comment) - potential workaround, but not that nice as As[T].

EDIT: I think that it would not solve the issues #78007 (comment) since it uses assignTo

[apparentlymart]

This use-case seems reasonable, but my initial intuition (from reading just the signature, before reading the details) was that this function would have equivalent behavior to assignment, respecting the assignability rules from the specification¹ instead of requiring exact type identity.

Do you think that respecting those rules would be reasonable, or would that still involve the sort of corner-cases you were hoping to exclude?

Footnotes

1. excluding any that are clearly not applicable to anything reflect can represent, such as untyped constants and predeclared identifiers ↩

[adonovan]

I think it would be confusing as proposed, because I would expect it to work for interface types T as well. For example. v.As[io.Reader]() should work for an *os.File. (Perhaps this is just a more concrete statement of @apparentlymart's objection.)

[mateusz834]

respecting the assignability rules from the specification

Do you think that respecting those rules would be reasonable

Isn't v.Set already made for such things?

but my initial intuition (from reading just the signature, before reading the details) was that this function would have equivalent behavior to assignment

because I would expect it to work for interface types T as well. For example. v.As[io.Reader] should work for an *os.File.

Maybe a different name would help, Unwrap was my other idea.

[mateusz834]

I think it would be confusing as proposed, because I would expect it to work for interface types T as well. For example. v.As[io.Reader] should work for an *os.File.

I see, but if As[T] followed the assignments rules, then when you do v.As[io.Reader]() you still don't know whether v.Type() == io.Reader or v.Type == implementation of io.Reader. This is the thing i want to avoid. Obviously you can check that type separately, but an additional thing to remember to do. And same case with underlying types could happen.

Nevertheless, the thing you all said, sound also like a reasonable thing to add, but this does not address the issues i mentioned.

[apparentlymart]

I suppose my intuition was that Value.As behaves as if it's assigning to a variable of type T and then returning a copy of that value.

I agree that seems similar to what Value.Set does, and so I suppose it would be possible for me to implement the function I had imagined in terms of Value.Set and your proposed Value.As, by doing something like this:

func valueAs[T any](v reflect.Value) (T, ok) {
    tmp := reflect.New(reflect.TypeFor[T]())
    // TODO: check if this assignment is actually possible
    // and return zero, false if not.
    tmp.Elem.Set(v)
    return tmp.Elem().As[T]()
}

This would, for example, allow using valueAs[io.Reader](f) where f is an *os.File, as @adonovan suggested.

So let's restate my original question as: is it important to separate the assignment from the "unpacking" in this way, or would it be reasonable to build that assignment effect into Value.As directly?

EDIT: @mateusz834 posted a comment answering this question simultaneously with me asking it. I'm understanding that checking for exact type identity is an important part of the use-case, though I'd love to learn more about why that's important.

[mateusz834]

I'd love to learn more about why that's important.

In my case I have hit CL 684675 in my code. Or more precisely a debugging utility. It was handling specially a specific interface type, when present as a field in a struct (or that was the intended behavior).

Something like:

type Foo interface {
	A()
}

type X struct {
	F Foo
}

func main() {
	val := reflect.ValueOf(&X{}).Elem()
	for _, f := range val.Fields() {
		if v, ok := reflect.TypeAssert[Foo](f); ok {
			fmt.Println(v) // not hit, since X.F == nil
		}
	}
}

And it causes a nil field not to be handled, since TypeAssert returns ok == false for such cases.

My point is that reflect does not currently make these kinds of special type checks easy, and it requires a number of extra checks just to ensure that the extracted value is actually of type T.

But now as I think As should be renamed to Unwrap/Unpack, just such that we can add Assign[T any] in future (if needed) and would not get confused with As[T].

I'd love to learn more about why that's important.

I think an Assign[T] would have solved that and not cause this issue, but i still believe that there should be mechanism to convert Value to a Go value with an identical type check.

With Assign[T] there are also these corner cases with underlying types say:

type Foo struct {
	A int
}

func main() {
	val := reflect.ValueOf(struct{ A int }{A: 3})
	val.Assign[Foo](val) // ok == true
}

But at least I think a val.Type() == reflect.TypeFor[Foo] would be enough to make this work as the initially proposed As.

[earthboundkid]

I tried to implement reflect.TypeAssert after it was approved, got hung up on the corner cases and bailed out. I think a simpler version that only goes through when the type is the same is good, although I'm not sure As is the right name, since it suggests a looser typing to me.

[mateusz834]

So I think that the proposal looks like this now (only a name change):

// Unpack attempts to unpack v into type T.
// It returns the value and true if v.Type() == reflect.TypeFor[T](),
// otherwise the zero value of T and false.
//
// Panics if the Value was obtained by accessing
// unexported struct fields.
func (v Value) Unpack[T any]() (val T, ok bool)