/cc @dsnet @mvdan

This is due to the encoder determining whether to quote the value while looking at the type of field (in this case reflect.Interface within typeFields). Since there are only a subset of types permitted and reflect.Interface is not one of them, quoted is never set to true. So when it gets to the intEncoder it’s not quoting the value.

Adding reflect.Interface to the list of allowed types has the desired effect for an int, but then if you put a slice of strings into the field, it will recursively encode the types and quote them, so you’ll end up with

{"Thing": ["\"val\""]} instead of the desired {"Thing": ["val"]}

The same is true for maps and any other data structure where it needs to recursively encode values.

This isn’t to say we shouldn’t fix these cases, but it provides some context as to why this is happening.

What @andybons said, pretty much. I agree the current docs can be confusing about this edge case, but I wonder if it's worth going through the trouble of changing the behavior of this edge case.

Perhaps a simpler fix is to clarify the docs. On the other hand, if someone wants to investigate a fix in the code, just be careful to not break any of the existing tests.

I investigated @andybons 's suggestion, and I noticed that it failed to the round-trip test. In the example of @docmerlin , the initial value, int(3), becomes string("3") after making a round trip.

Is there any suggestion? I want to investigate more.