-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: clarify merge semantics of Unmarshal #27172
Labels
Documentation
Issues describing a change to documentation.
NeedsFix
The path to resolution is known, but the work has not been done.
Milestone
Comments
Change https://golang.org/cl/148834 mentions this issue: |
Change https://golang.org/cl/221117 mentions this issue: |
The first CL hasn't been updated after the last round of reviews, and I'm tackling a related documentation issue as well, so I've sent a CL of my own. |
moskyb
added a commit
to buildkite/go-buildkite
that referenced
this issue
Oct 16, 2024
… than unmarshalling into the input encoding/json behaves surprisingly ([#27172](golang/go#27172), [#31924](golang/go#31924), [#26946](golang/go#26946), [#21092](golang/go#21092)) when unmarshalling into non-empty structs, and this behaviour is unexpected in this library anyway; no other methods do any user-facing unmarshalling or pointer mutation. This commit changes all of the `Update` methods that unmarshall into their inputs to no longer do that, and return a newly-allocated struct instead.
moskyb
added a commit
to buildkite/go-buildkite
that referenced
this issue
Oct 16, 2024
… than unmarshalling into the input encoding/json behaves surprisingly ([#27172](golang/go#27172), [#31924](golang/go#31924), [#26946](golang/go#26946), [#21092](golang/go#21092)) when unmarshalling into non-empty structs, and this behaviour is unexpected in this library anyway; no other methods do any user-facing unmarshalling or pointer mutation. This commit changes all of the `Update` methods that unmarshall into their inputs to no longer do that, and return a newly-allocated struct instead.
moskyb
added a commit
to buildkite/go-buildkite
that referenced
this issue
Oct 16, 2024
… than unmarshalling into the input encoding/json behaves surprisingly ([#27172](golang/go#27172), [#31924](golang/go#31924), [#26946](golang/go#26946), [#21092](golang/go#21092)) when unmarshalling into non-empty structs, and this behaviour is unexpected in this library anyway; no other methods do any user-facing unmarshalling or pointer mutation. This commit changes all of the `Update` methods that unmarshall into their inputs to no longer do that, and return a newly-allocated struct instead.
moskyb
added a commit
to buildkite/go-buildkite
that referenced
this issue
Oct 16, 2024
… than unmarshalling into the input encoding/json behaves surprisingly ([#27172](golang/go#27172), [#31924](golang/go#31924), [#26946](golang/go#26946), [#21092](golang/go#21092)) when unmarshalling into non-empty structs, and this behaviour is unexpected in this library anyway; no other methods do any user-facing unmarshalling or pointer mutation. This commit changes all of the `Update` methods that unmarshall into their inputs to no longer do that, and return a newly-allocated struct instead.
moskyb
added a commit
to buildkite/go-buildkite
that referenced
this issue
Oct 16, 2024
… than unmarshalling into the input encoding/json behaves surprisingly ([#27172](golang/go#27172), [#31924](golang/go#31924), [#26946](golang/go#26946), [#21092](golang/go#21092)) when unmarshalling into non-empty structs, and this behaviour is unexpected in this library anyway; no other methods do any user-facing unmarshalling or pointer mutation. This commit changes all of the `Update` methods that unmarshall into their inputs to no longer do that, and return a newly-allocated struct instead.
moskyb
added a commit
to buildkite/go-buildkite
that referenced
this issue
Oct 16, 2024
… than unmarshalling into the input encoding/json behaves surprisingly ([#27172](golang/go#27172), [#31924](golang/go#31924), [#26946](golang/go#26946), [#21092](golang/go#21092)) when unmarshalling into non-empty structs, and this behaviour is unexpected in this library anyway; no other methods do any user-facing unmarshalling or pointer mutation. This commit changes all of the `Update` methods that unmarshall into their inputs to no longer do that, and return a newly-allocated struct instead.
moskyb
added a commit
to buildkite/go-buildkite
that referenced
this issue
Oct 16, 2024
… than unmarshalling into the input encoding/json behaves surprisingly ([#27172](golang/go#27172), [#31924](golang/go#31924), [#26946](golang/go#26946), [#21092](golang/go#21092)) when unmarshalling into non-empty structs, and this behaviour is unexpected in this library anyway; no other methods do any user-facing unmarshalling or pointer mutation. This commit changes all of the `Update` methods that unmarshall into their inputs to no longer do that, and return a newly-allocated struct instead.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Documentation
Issues describing a change to documentation.
NeedsFix
The path to resolution is known, but the work has not been done.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?Go playground
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?Go playground
What did you do?
https://play.golang.org/p/QM3FKwmR9h1
What did you expect to see?
What did you see instead?
In short...
The Unmarshal documentation says:
~ https://golang.org/pkg/encoding/json/#Unmarshal
I assumed that after Unmarshal returns, the struct would exactly match the provided JSON. I found this quite surprising and I think the documentation should mention that "Fields that are not present in the JSON document will retain their original values."
The existing functionality does give one an elegant way to set default values by having Unmarshal only update those fields which are present in the JSON document. I do not dispute that it is useful. Still, I would like to see the documentation mention this behaviour explicitly.
The text was updated successfully, but these errors were encountered: