I thought I'd seen this before, but I can't find another issue in this tracker.

Have you tried alternatives, such as merging the maps afterward?

I also assume that if we're to make the decoder incremental, it should be consistent across all types - struct fields and slices too, for example.

I have tried to merge map afterwards, but I encountered the following issues:

• How to detect that field was specified in input data. (pointers can be used for this, but it is convenient)
• map[string]T which predefined items, where T is an interface cannot be used as target for Decode.

enconding/json do not override struct fields and the structure can be used instead of map.

Because it wasn't clear to me, this is not about reusing a map during Unmarshal, which Unmarshal already does, but instead about some way to merge a specific values contained in the map already under a given key with the new data in the JSON value with the same key. In general this is not a well-formed operation, so it would have to be opt-in. It seems too specialized to be worth the complexity it would incur in package json. (Package json is already quite complex.)

If you really need this, my suggestion would be to write a custom merger or to fork the json package and modify your own copy.

@rsc I do not agree. When I unmarshal structure, the fields already reused.
when I unmarshal map, the items always re-created. IMHO, the behaviour should identical.
and this is not about merge, it is about re-using existing map values instead of creating a new one, which also implemented for struct fields.

In both the struct and the map case, a specific element is being updated. In your example, you are updating the map element for the key "a". You are asking for something further: you want to say that if the map element for the key "a" already exists, you want to update only specific fields. As Russ said, you want a merge operation.

in case of struct, elements which are not specified in json keeps they original values.
in case of using map, the whole map will be constructed from scratch.

https://play.golang.org

@bgaifullin, I see your point, and if we were designing json from scratch, we'd probably sit down and think about whether the struct semantics should be changed or the map semantics should be changed or it's OK for them to be subtly different in this way. But we're not designing json from scratch. We have many existing uses that must be taken into account, and I am sure that we cannot change the default behavior here without breaking some existing uses. That leaves us with adding an option that we must maintain, or encouraging people who need this merge semantics to build their own. For now at least we are choosing the latter. If evidence accumulates that merging into existing map values is needed by many users then we will certainly revisit this.

@rsc I got it. thank you.