encoding/json: unexpected json.Unmarshal behavior with maps

[nandosousafr]

http://golang.org/src/encoding/json/decode.go?s=2621:2669#L64

To unmarshal a JSON object into a map, Unmarshal replaces the map with an empty map and then adds key-value pairs from the object to the map.

But, while unmarshalling it behaves differently.

http://play.golang.org/p/HTjkkCEQBV

var r map[string]string
j := []byte(`{"hello": "world"}`)

json.Unmarshal(j, &r)
fmt.Println(r)
// map[string]string{"hello":"world"}

ja := []byte(`{"world": "hello"}`)
json.Unmarshal(j, &r)
fmt.Println(r)
// map[string]string{"hello":"world", "world":"hello"}
// expected to eq map[string]string{"world": "hello"}

I'm totally in favor of this behavior but what docs is saying isn't correct.

That make sense?

[dominikh]

749b391 added said documentation and a test for the behaviour. Unfortunately, the test itself is broken, too. https://github.com/golang/go/blob/master/src/encoding/json/decode_test.go#L313 is supposed to test the overwriting of the map. However, in https://github.com/golang/go/blob/master/src/encoding/json/decode_test.go#L536 the initial value gets thrown away and replaced with an empty map. That way, the test doesn't actually test the overwriting of the map.

[dominikh]

Furthermore, this doesn't look like a regression. It does still overwrite slices; and Go 1.4.2 didn't overwrite maps, either.

[sillyousu]

http://play.golang.org/p/HTjkkCEQBV
Unmarshal resets slice, but doesn't rest map. I think they should have the same behavior.

https://github.com/golang/go/blob/release-branch.go1.5/src/encoding/json/decode.go#L521

[nodirt]

Fix: https://go-review.googlesource.com/#/c/16020/

[gopherbot]

CL https://golang.org/cl/16020 mentions this issue.

[rakyll]

/cc @rsc

[rsc]

It's entirely possible we should change the docs instead of changing the implementation.

[james-lawrence]

seems like not changing one of the implementations (slices or maps) leads to inconsistency in the api. if that matters at all in your decision.

[gopherbot]

CL https://golang.org/cl/17230 mentions this issue.