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

Jump to bottom

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

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

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

titanous opened this issue Feb 24, 2013 · 9 comments
Labels
FrozenDueToAge
Milestone
Go1.2

Comments

@titanous
Copy link
Member 

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
Copy link
Contributor

rsc commented Feb 25, 2013

Comment 1:

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

@titanous
Copy link
Member Author

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
Copy link
Member Author

Comment 4:

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

@rsc
Copy link
Contributor

rsc commented Mar 12, 2013

Comment 5:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

@adg
Copy link
Contributor

adg 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
Copy link
Member Author

Comment 7:

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

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 8:

Labels changed: added go1.2maybe.

@rsc
Copy link
Contributor

rsc 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
Copy link
Contributor

rsc commented Sep 9, 2013

Comment 10:

This issue was closed by revision 5d2c3a6.

Status changed to Fixed.

@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.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.2
Development

No branches or pull requests
4 participants
@titanous @rsc @adg @gopherbot