I think the problem is slightly different than #10, what I am looking at is in json tag, like

type User struct {
	DID string `json:"DID ,omitempty"`
	SID string `json:"SID,omitempty"`
}

so if the upstream sends out like "sid" instead of "SID", default JSON can parse correctly but easyjson can not , even use -snake_case flag dose not help. any idea how to make it more unique?

re-surface this issue as it is quite significant blocking for us

@vstarodub saw your comments in #10 , but my question seems to be different, do you know whether easyjson can easily support this?

Thanks
Rui

stdlib works in runtime, so it cant try to look various name for fields.

easyjson now generates code, which parse only one name per field. camelCase, snake_case or from struct tags.

To support parsing from various name we need to add this feature to generator. PR are welcome

any idea when this can be prioritized? I would like to see it is quite high demand feature as lots of JSON situation we can not control counter partener behavior on case sensitive

Thanks
Rui

hm, case insensitive match is not a high priority feature, because it slows runtime too much. Too much allocations, unfortunately. So its better to use pre-defined json and not to have deal with insensitive case.

I understand, but actually I think you can provide as option, and just convert all keys to lower case in your current match instead keep the original. maybe in this way, the overhead will be minimum?

It can be achieved with some patches in generator. But the memory overhead is very large)

hmm, I am not seeing why memory overhead is large. in current parser you just get raw key, my suggestion is with this "case insensitive option", to a tolower(key) instead of directly use key.

anyway, if marshall/unmarshall speed can still beat general python, I am not that much worried about memory neither:)

I think youre always allowed to implement this feature)

If someone is interested I've implemented it here: #372

In the arduino-cli project we are using the patch with success, it would be great to see it merged upstream.