Could you provide a full self-contained example, please?

Also, note that the current Go version is 1.12; 1.10 is about a full year behind on the latest changes to encoding/json.

This snippet should hit the same problem,

package main

import (
	"encoding/json"
	"log"
)

func main() {
	type C struct {
		ID   string `json:"-"`
		Name string `json:"name"`
	}

	type A struct {
		B map[string]C `json:"b"`
	}

	byt := []byte(`
	{
		"b": {
			"string0": {
				"name": "name0"
			},
			"string1": {
				"name": "name1"
			}
		}
	}
	`)
	b := map[string]C{
		"string0": C{ID: "42", Name: ""},
		"string1": C{ID: "53", Name: ""},
	}
	a := A{B: b}
	log.Println("current value of a:", a)

	if err := json.Unmarshal(byt, &a); err != nil {
		log.Fatalln(err)
	}
	log.Println("current value of a:", a)
}

$ PATH=/home/g/opensource/go/bin:$PATH go version
go version go1.10.1 linux/amd64
$ PATH=/home/g/opensource/go/bin:$PATH go run main.go 
2019/03/09 18:06:42 current value of a: {map[string1:{53 } string0:{42 }]}
2019/03/09 18:06:42 current value of a: {map[string0:{ name0} string1:{ name1}]}

After unmarshalling, ID's are overwritten and set to the default value for string.

I can reproduce that with current master (05051b5) too.

Thanks a lot for the effort @giuscri i was about to create it. Here it is as a playground: https://play.golang.org/p/gBJ9aa_Tbbf

So it appears you discovered the "-" tag is broken event for simple sub types (my test was refering to a complex map as subfield), but indeed a string will be reset to default value too.

Note that the problem is not reproducible on simpler unmarshalling such as

	type B struct {
		ID   string `json:"-"`
		Name string `json:"name"`
	}

https://play.golang.org/p/Axvw-A5zpTs

Yes, first level fields tagged with "-" are ignored properly, the issue arise only in sub structures (potentially only in sub maps?).

@mvdan Are the infos provided enough? If yes can we hope this to be fixed? This issue is quite big for anyone trying to build real life POST apis with complex structures...

Regards,

@mvdan ping, I think all infos provided should be enough, could we remove the "WaitingForInfo" and treat the bug?

Regards,

The information should be enough. I don't have the bandwidth to look at this bug right now, though.

I see, thanks @mvdan ! Do you have any idea of when you'd have time to handle it? If not possible in the foreseeable future, I'll have to reconsider the architecture of my project and go for another solution. Thanks a lot,

Go releases happen every six months, so even if a fix was out today, you wouldn't be able to use it for another four months. If you need an urgent fix, I'd suggest forking the package and hacking it to do what you want.

The code you have provided works correctly.
From the json doc:
To unmarshal a JSON object into a map, Unmarshal first establishes a map to use. If the map is nil, Unmarshal allocates a new map. Otherwise Unmarshal reuses the existing map, keeping existing entries. Unmarshal then stores key-value pairs from the JSON object into the map.

Notice the last sentence, which says it replaces not merges values.

Hm i see, but then it's a design choice that is IMOH very weird. Real-life data is almost always complex and with multiple depth levels, which either needs to send partial data for perf reason, or just can't represent data full structure over JSON (ex: function handlers, map with non primitive types as key, etc). This prevent using go in any real life complexe situation, should this be considered an appropriate feature request? Or do you think it's too much of a change and might break existing application logic that rely on these sub-values be reinitialised?