proposal: add a json struct tag option that would (un)marshal a struct into an array

[urandom]

Consider the following scenario:

You want to handle a jsonrpc (or similar) styled json and now you have to deal with the arguments field. However, since that field is more often than not a json array of various things, you'll have to do it manually if you want to avoid casting all of its members later.

So you'd go with the following route:
http://play.golang.org/p/mDSjNsa3P9

It would be nice if the json package did that for you. It might be handled similarly to how the "string" option works now.

If you have an inner struct, it might have a tag json:",array" which would single that it should be treated as an array with a length that's governed by its keys. And "omitempty" would be ignored, since it makes no sense in that context.

Unfortunately, go doesn't support tags on the outer struct (I'm curious as to why that is), so maybe a set of functions could be added that emulate the process for the outer struct only:

json.MarshalArray
json.UnmarshalArray

[spenczar]

As you note, tags apply to struct fields, so this is a big change.

The json package has Marshaler and Unmarshaler interfaces that it will use though, and this seems like an excellent example of their utility - you can use them for any wacky serialization schemes. In your example, one needs to write MarshalJSON and UnmarshalJSON methods on *Args, but that's not hard: http://play.golang.org/p/ITWcAJ7dTR

I think this is a much simpler solution that doesn't require expanding json tags to be applicable to type declarations.

[urandom]

@spenczar, sure, using the interfaces is a solution, which I already use (the play link just illustrates the proposal). Supporting an "array" tag, even on struct fields only, is much faster for this type of problem, and will probably help a lot of people that currently unmarshal json into an interface slice and then type check each item in the slice by hand, since stuffing your actual pointers into an interface slice is not what people think of first when they bump into this sort of problem.

[bradfitz]

Unfortunately I think we're going to have to say no here. The json package has been growing too many features and it's time to say no to additions and let it be stable. In the future we may want to move development to an external package with more features, once we have a list of all such features.