proposal: encoding/json: Unmarshal support for dynamic types

[anpez]

I'd love to see a version of json.Unmarshal that accepts a type selector. E.g. a function that, given the to-be-decoded json returns the type that should be unmarshalled.

This is very useful if you are reading a JSON array where the elements don't all have the same fields and you are ok with a heterogeneous array.

Say you have this JSON:

[{"a":1}, {"b":2}]

and you want the unmarshalled array to be like this

[]interface{}{A{A: 1}, B{B: 2}}

you could pass in a function to Unmarshal that, given the map[string]interface{} containing every one of the elements would return an empty struct to be unmarshalled to. These would, of course, slow the things down as it would require double unmarshalling.

[ianlancetaylor]

What would the type of the empty struct be in your example? How would people use this in practice?

[anpez]

That empty struct would be the specific type, based on some information on the element itself. Could be something like this:

func getType(element map[string]interface{}) interface{} {
    if element["type"] == "type1" {
        return &structType1{}
    }
    return &structType2{}
}

GIven the returned empty struct, probably with anotations json:"..", json.Unmarshal would unmarshal into it, as usual.

[rsc]

I don't think this proposal makes a convincing case for the complexity being added. When does this come up? "If you are reading a JSON array where the elements don't all have the same fields..." but that doesn't sound like an array to me. Does anything in common use do this? We tend not to extend the standard library for hypotheticals.

Note also that you can already make a []map[string]interface{} and do this yourself. You can also use a []json.RawMessage and then process each array entry separately, as makes sense.

[anpez]

Makes sense when working with inheritance. Structs that embed others, and you want each of them to have their properties.

[adg]

While I think this is a reasonable request, we need to stop making changes to the encoding/json package. It is already complicated enough, and changes introduce bugs. If this feature is important to people, it should be implemented in a package outside the standard library.

Closing this issue. Thanks for your time.