Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to prefer text unmarshaler when data type is String #371

Open
wants to merge 1 commit into
base: v5
Choose a base branch
from

Conversation

WGH-
Copy link

@WGH- WGH- commented Feb 27, 2024

This library currently always prefers to use encoding.BinaryUnmashaler when it's implemented by the target type.

This might lead to problems when the type also has a text representation implemented as encoding.TextUnmarshaler.

Consider netip.Addr from stdlib as example, which implements both. This library won't be able decode MessagePack containing a string "192.0.2.1" into *netip.Addr because it will attempt to use encoding.BinaryUnmashaler which doesn't expect text representation.

Fortunately, MessagePack has distinct string and binary types, so we can check the source data type before choosing the interface to use.

This commit changes the behaviour of decoder as follows. When

  1. target Go data type implements both BinaryUnmashaler and
    TextUnmarshaler
  2. source MessagePack data type is a string

TextUnmarshaler will be preferred over BinaryUnmashaler.

This feature is gated behind a Decoder option, because it is potentially backward-incompatible change.

See #370

This library currently always prefers to use encoding.BinaryUnmashaler
when it's implemented by the target type.

This might lead to problems when the type also has a text
representation implemented as encoding.TextUnmarshaler.

Consider netip.Addr from stdlib as example, which implements both.
This library won't be able decode MessagePack containing a string
"192.0.2.1" into *netip.Addr because it will attempt to use
encoding.BinaryUnmashaler which doesn't expect text representation.

Fortunately, MessagePack has distinct string and binary types, so we can
check the source data type before choosing the interface to use.

This commit changes the behaviour of decoder as follows. When

1) target Go data type implements both BinaryUnmashaler and
   TextUnmarshaler
2) source MessagePack data type is a string

TextUnmarshaler will be preferred over BinaryUnmashaler.

This feature is gated behind a Decoder option, because it is potentially
backward-incompatible change.

See vmihailenco#370
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant