Repository navigation
encoding/json/v2: remove recursive nature of string tag option #79065
Description
Proposal Details
The current prototype of json/v2 allows the string tag option to be recursive. For example:
json.Marshal(struct{
Foo []int `json:",string"`
}{Foo: []int{1, 2, 3}})would result in:
{"Foo": ["1", "2", "3"]}
This is in contrast to v1 behavior, which silently ignore the string tag option on composite Go types.
In the working group, we decided to remove the recursive nature of string since none of the other tag options are recursive in nature. With typed struct tags coming in the horizon, it increasingly looks like most tag options would be non-recursive in nature (i.e., they only affect the immediate field value). Of course, there exist reasonable use-cases where you want an option to be recursive, but we would probably design a typed-struct tag API to express that intent. Thus, the general precedence is that tags are non-recursive by default.
We will remove support for string tag option on composite types and (if running under v2-semantics, to instead report a runtime error).
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
gabyhelp commentedon May 1, 2026
Related Issues
Related Code Changes
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)
aclements commentedon May 7, 2026
@dsnet , FYI, I'd prefer this to be fixed before we flip the GOEXPERIMENT flag.
prattmic commentedon May 15, 2026
I agree that v2 should report a runtime error if the string tag appears on an unsupported type, but it is unclear to me which option this behavior should be associated with.
The primary option regarding the string tag is
encoding/json.StringifyWithLegacySemantics, which will have the following baseline behavior:encoding/json.StringifyWithLegacySemantics(true)(v1): The string tag takes effect on fields where the top-level type is a bool, string, numeric kind, or a pointer to such a kind.encoding/json.StringifyWithLegacySemantics(false)(v2): The string tag takes effect on fields where the top-level type is a numeric kind, or a pointer to such a kind.(i.e., v2 drops bool and string)
One option is to tie the errors to this option. So
true/v1 ignores the tag on invalid fields andfalse/v2 reports an error if the tag appears on an invalid field.Alternatively, we could tie the errors to
encoding/json.ReportErrorsWithLegacySemantics. Sotrue/v1 ignores invalid fields, andfalse/v2 reports errors.I lean slightly towards this as the better choice, since
ReportErrorsWithLegacySemanticssays "if a Go struct contains type errors(e.g., conflicting names or malformed field tags), then such errors are ignored and the Go struct uses a best-effort representation. In contrast, the v2 semantic is to report a runtime error."I suppose that placing the string tag on the wrong type of field qualifies as a "malformed field tag"?
What gives me pause is that the implementation of
StringifyWithLegacySemantics(true)does not currently report errors ifReportErrorsWithLegacySemantics(false)(there should be anelse if mo.Flags.Get(jsonflags.ReportErrorsWithLegacySemantics) { return err... }case). It's unclear to me if this is an oversight, or I have misunderstood the intention.cc @dsnet @aclements @neild @ChrisHines let me know if you have an opinion.
ChrisHines commentedon May 15, 2026
I think tying the error to either of those settings can be justified. Based on the current documentation for the two options, though, I think it is a slightly better fit to tie the errors to
encoding/json.ReportErrorsWithLegacySemantics.gopherbot commentedon May 18, 2026
Change https://go.dev/cl/779300 mentions this issue:
encoding/json/v2: remove recursion and error onstringon unsupported typeencoding/json/v2: remove recursion and error on `string` on unsupport…
gopherbot commentedon May 19, 2026
Change https://go.dev/cl/779940 mentions this issue:
encoding/json/v2: add string option hint optimizationencoding/json/v2: add string option hint optimization
gopherbot commentedon May 28, 2026
Change https://go.dev/cl/784040 mentions this issue:
encoding/json/v2: use option flags to signal presence of tagsencoding/json/v2: use option flags to signal presence of tags