encoding/json accepts case-insensitive keys, while easyjson doesn't

[ghost]

t2.go:

package t2

type S struct {
    A int
}

t2_test.go:

package t2

import (
    "encoding/json"
    "strings"
    "testing"
)

func TestCaseInsensitiveDecoding(t *testing.T) {
    d := json.NewDecoder(strings.NewReader(`{"a":1}`))
    var s S
    err := d.Decode(&s)
    if err != nil {
        t.Fatal(err)
    }
    if s.A != 1 {
        t.Fatal("expected 1, got", s.A)
    }
}

Without easyjson-generated code the test is passed; with it it fails:

t2_test.go:17: expected 1, got 0

This behaviour should be either documented or fixed.

[dAdAbird]

Yeah, got this too!
It's fixes by -snake case flag on easyjson generating.
Nevertheless, this behavior should be documented or brought to encoding/json.

Thanks!

[vstarodub]

I'm thinking about adding case-insensitive keys as an option which is turned off by default since case insensitivity will hurt the performance somewhat.

snake_case option in not exactly the same as lowercase: it also adds underscores between consecutive words.

[heynemann]

Any idea on when this will hit a released version? I need this bad. It would kill every single user of my API if I had to change the payloads they send me. On the other hand, having easyjson decode the payloads speeds up my app considerably.

[heynemann]

Btw, in order NOT to get the performance penalty, one easy way of achieving the same would be hinting EasyJSON with the json name. Something like:

type MyType struct {
   SomeField string `json:"someField"`
}

Very much like encoding/json already does.

Thanks for the great work.

[heynemann]

I'm sorry, I just found out that the json comment already works. Sorry for that.

[vstarodub]

Yes, json tags work. Sorry I haven't explicitly pointed that out as a workaround.

I did experiment with standard name matching, but I was unable to come up with a version without significant performance penalty. The issue here is not case insensitivity, but mostly having "better" and "worse" matches in 'encoding/json'. Adding this logic makes the serializer slow, defeating the whole purpose of using a non-standard json serializer.

For me it looks like this: if you don't care about performance at all, you should probably use "encoding/json". If you do, using tags is not a huge overhead and there will be no magic name matching involved. Less magic = predictable performance.

I'm closing this as wontfix. If tags are not enough — feel free to reopen with a use case.