Proposal Details
(This is a counter-proposal to #76444).
The json/v2 package provides too much functionality with unknown fields:
- A Go struct field may be marked as
unknown to indicate that it holds unknown members. Note that this is nearly identical to the existing inline tag option, but additionally indicates intent for holding unknown members.
- DiscardUnknownMembers discards unknown members when marshaling by ignoring any data in Go struct fields marked as
unknown.
- RejectUnknownMembers rejects unknown members when unmarshaling (even if a Go struct field is marked as
unknown) by reporting an error.
I propose removing the unknown tag option and the DiscardUnknownMembers option. Note that RejectUnknownMembers still needs to exist to maintain backwards compatibility with the jsonv1.Decoder.DisallowUnknownFields feature.
We could always re-introduce the concept of Go struct fields marked as unknown in a future release of json/v2, but then we would need to think about how all related options might interoperate (see #76444). Fortunately, adding new features is always backwards compatible, but removing or changing them is not.
Proposal Details
(This is a counter-proposal to #76444).
The
json/v2package provides too much functionality with unknown fields:unknownto indicate that it holds unknown members. Note that this is nearly identical to the existinginlinetag option, but additionally indicates intent for holding unknown members.unknown.unknown) by reporting an error.I propose removing the
unknowntag option and theDiscardUnknownMembersoption. Note thatRejectUnknownMembersstill needs to exist to maintain backwards compatibility with thejsonv1.Decoder.DisallowUnknownFieldsfeature.We could always re-introduce the concept of Go struct fields marked as
unknownin a future release ofjson/v2, but then we would need to think about how all related options might interoperate (see #76444). Fortunately, adding new features is always backwards compatible, but removing or changing them is not.