Related Issues and Documentation

• encoding/json: Unmarshal an interface pointer bug #21494 (closed)
• encoding/json: Unmarshal replaces interface{} types instead of acting on the underlying type #20994 (closed)
• encoding/json: Unmarshal map[string]interface{} target mishandled when passed as an interface{} #33487 (closed)
• encoding/json: fix Unmarshal of value assigned to an interface variable.
• encoding/json: resolve struct, map, array, or slice values in interface types
• json.Unmarshal not work good at object #48959 (closed)
• encoding/json: Unmarshal into *interface{} that contains specific value #6640 (closed)
• encoding/json: clarify what happens when unmarshaling into a non-empty interface{} #26946
• encoding/json: cannot unmarshal custom interface value #45512
• all: revise reflect.Type/reflect.Value NumMethod usage after CL 259237 #41882 (closed)

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

Change https://go.dev/cl/619995 mentions this issue: encoding/json: fix Unmarshal of value assigned to an interface variable.

I think this is just a misunderstanding in the logic surrounding the call to Unmarshal. If you pass Unmarshal a *any, it will produce a result consisting of untyped map[string]any values. Instead, pass (an any value containing) a pointer to a struct type, like so:

https://go.dev/play/p/-1ceojzwcMT

	type S struct {
		X int
	}
	var s S
	var i any = reflect.ValueOf(&s).Interface()
	_ = json.Unmarshal([]byte(`{"X":1}`), i)
	fmt.Println(reflect.TypeOf(i)) // "*main.S"

Duplicate of #26946

@adonovan Thank you, that's a useful workaround having the interface variable assigned to a pointer. I do still think it's an issue thought, that Unmarshal can't handle the pointer of the interface variable.

@seankhliao sorry, I missed that, I will add the older issue number to the fix

@adonovan Thank you, that's a useful workaround having the interface variable assigned to a pointer. I do still think it's an issue though, that Unmarshal can't handle the pointer of the interface variable.

Unmarshal is handling the pointer to the interface variable exactly as documented. If you want it to populate a struct variable, you need to give it a pointer to a struct variable.

@adonovan Well, the problem is that I expected it to be unmarshaled into an underlying struct because as far as I understand an interface is not a value, it's more like a constraint on a struct. So unmarshaling into an empty interface doesn't make much sense to me.

@adonovan Well, the problem is that I expected it to be unmarshaled into an underlying struct because as far as I understand an interface is not a value, it's more like a constraint on a struct. So unmarshaling into an empty interface doesn't make much sense to me.

An interface type is indeed a kind of constraint: it's the subset of all types that have a particular set of methods. But an interface value is a value capable of representing a variety of (or perhaps any) concrete types: conceptually it is a pair of a concrete type and a value of that type. When you unmarshal into a variable whose type is any, the decoder may update the variable to hold one of half a dozen concrete types: int, float, string, slice, map, or nil.

@adonovan Yes, that's the use case for the empty any interface, which I kept in the fix. But if an interface has been assigned to a certain type as it is supposed, it would seem Unmarshal should work on the underlying type, because the interface is supposed to be assigned to something.

Personally I think the current behavior is fine.

Much more importantly, we can't change the current behavior. It would certainly break existing working programs.

Unmarshal wants a pointer to a variable, which it will update. The type of that variable determines what representation Unmarshal will use. Because Unmarshal long preceded generics, the only way for it to say "I need a pointer to something" is to have a parameter of type any. Your code gave Unmarshal a value of type pointer-to-any, so you requested the dynamic representation (map, etc). It doesn't matter than the variable already contained a value (a pointer to a struct): Unmarshal will overwrite it.

@ianlancetaylor It would only break programs which assign non-map[string]any value to an interface variable and then expect map[string]any. It's hard to imagine anyone relying on such behaviour.
I think the current behavior is unintuitive because an interface variable is supposed to have a value implementing that interface and the Unmarshal function doesn't consider it.
Besides converting a non-nill any type variable into a map, it creates a weirder result for an interface variable with methods. It doesn't do anything to it. Here's an example. And I would have expected it to change.

@ianlancetaylor It would only break programs which assign non-map[string]any value to an interface variable and then expect map[string]any. It's hard to imagine anyone relying on such behaviour.

Unmarshal has always clobbered the contents of the variable, making it independent of whatever junk happened to be in it. Breaking that invariant would certainly break existing programs.

I think the current behavior is unintuitive because an interface variable is supposed to have a value implementing that interface and the Unmarshal function doesn't consider it. Besides converting a non-nill any type variable into a map, it creates a weirder result for an interface variable with methods. It doesn't do anything to it. Here's an example. And I would have expected it to change.

The error returned by Unmarshal explains the problem: "json: cannot unmarshal object into Go value of type main.I". This program is another example of "holding it wrong" by passing Unmarshal an interface variable that it cannot possibly update with any simple JSON value.

@adonovan I'm confused, there's no error in the example

@adonovan I'm confused, there's no error in the example

Unmarshal returns an error, but your example code ignores it. Here's what happens if you report it: https://go.dev/play/p/Mhi3Xlasdmd.

@adonovan got it, sorry, missing error handling, my fix would unmarshal it though.
As for breaking changes, I see how you could use any type variable for a map and then for an array, but my fix would try to Unmarshal into a map the second time.
However, I could keep the same behaviour by making any type variable always be converted into a map, array, what have you)