Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

encoding/json: concrete types of existing map keys are not respected #4900

Closed
titanous opened this issue Feb 24, 2013 · 9 comments

Comments

Projects
None yet
4 participants
@titanous
Copy link
Member

commented Feb 24, 2013

What steps will reproduce the problem?

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

What is the expected output?

map[string]interface {}{"key2":42, "nested": &Nested{Name:
"foo"}, "key1":map[string]interface
{}{"key":"val"}}

What do you see instead?

map[string]interface {}{"key2":42, "nested":map[string]interface
{}{"name":"foo"}, "key1":map[string]interface
{}{"key":"val"}}

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

OS 10.8.2

Which version are you using?  (run 'go version')

go version devel +886c91b4ae3c Sun Feb 24 17:19:09 2013 +0100 darwin/amd64

Please provide any additional information below.

I've created a CL that fixes this issue: https://golang.org/cl/7369049/
@rsc

This comment has been minimized.

Copy link
Contributor

commented Feb 25, 2013

Comment 1:

Not 100% sure this is a backwards-compatible change. Do the docs promise
the new behavior?
@titanous

This comment has been minimized.

Copy link
Member Author

commented Feb 25, 2013

Comment 2:

I believe so:
> To unmarshal JSON into an interface value, Unmarshal unmarshals the JSON into the
concrete value contained in the interface value.
@titanous

This comment has been minimized.

Copy link
Member Author

commented Feb 27, 2013

Comment 4:

Oops, I just realized that the CL link is wrong. This is the correct link:
https://golang.org/cl/7383052/
@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2013

Comment 5:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

@adg

This comment has been minimized.

Copy link
Contributor

commented Apr 8, 2013

Comment 6:

quoth rsc:
"I'm sorry but I can't convince myself that these are the semantics we want.
I'd rather live with the Go 1.0 bug than introduce a new Go 1.1 bug. Let's
leave this for after Go 1.1."

Labels changed: added priority-later, removed priority-triage.

Status changed to Thinking.

@titanous

This comment has been minimized.

Copy link
Member Author

commented Apr 17, 2013

Comment 7:

Here's another example, this time with structs: http://play.golang.org/p/lXhGNrStXx
@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 8:

Labels changed: added go1.2maybe.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 9, 2013

Comment 9:

The behavior in the current code does disagree with the docs.
However, the behavior appears to be consistent for all places
interface values are encountered; maps are not the odd man out.
Given that, I believe the fix should be to document the true behavior,
not to change the behavior this late in the game.
Sent CL 13400044.
@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 9, 2013

Comment 10:

This issue was closed by revision 5d2c3a6.

Status changed to Fixed.

@titanous titanous added fixed labels Sep 9, 2013

@rsc rsc added this to the Go1.2 milestone Apr 14, 2015

@rsc rsc removed the go1.2maybe label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 24, 2016

@golang golang deleted a comment from gopherbot Dec 23, 2017

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.