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:
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).
Proposal Details
The current prototype of json/v2 allows the
stringtag option to be recursive. For example:would result in:
This is in contrast to v1 behavior, which silently ignore the
stringtag option on composite Go types.In the working group, we decided to remove the recursive nature of
stringsince 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
stringtag option on composite types and (if running under v2-semantics, to instead report a runtime error).