You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The key piece of the above playground is that, if a struct type has a method MarshalJSON with a pointer receiver, and if there's a field of of a struct with the non-pointer type, the behavior diverge: the stdlib's encoding/json doesn't call MarshalJSON, but Jsoniter does. In the playground linked above, this is shown on the serialization of the field BarNoPtr.
Now, I'm not claiming that Jsoniter's behavior is incorrect (I think it's reasonable behavior; in the very least, it's much more consistent than stdlib's behavior, as the full playground shows). The issue I'm bringing up is specifically the claim of 100% compatibility when using jsoniter.ConfigCompatibleWithStandardLibrary.
The text was updated successfully, but these errors were encountered:
According to the docs, it's possible to get 100% compatibility with the standard lib:
I found a case in which this doesn't happen: https://go.dev/play/p/fSAa6wRtDKA
The key piece of the above playground is that, if a struct type has a method
MarshalJSON
with a pointer receiver, and if there's a field of of a struct with the non-pointer type, the behavior diverge: the stdlib'sencoding/json
doesn't callMarshalJSON
, but Jsoniter does. In the playground linked above, this is shown on the serialization of the fieldBarNoPtr
.Now, I'm not claiming that Jsoniter's behavior is incorrect (I think it's reasonable behavior; in the very least, it's much more consistent than stdlib's behavior, as the full playground shows). The issue I'm bringing up is specifically the claim of 100% compatibility when using
jsoniter.ConfigCompatibleWithStandardLibrary
.The text was updated successfully, but these errors were encountered: