RFC: Support deserializing enum values in internally/untagged enums #2692
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch adds support for deserializing enum values in internally/untagged enums. E.g.:
At the moment, if the
Deserializer
knows thatInner
is an enum and callsvisit_enum
(e.g., a self-describing format that understands enums), this error will be triggered:serde/serde/src/private/de.rs
Lines 517 to 519 in ede9762
I'm working around this issue by serializing the variant as a
Content
and visiting the value withEnumAccess::newtype_variant::<Content>
.There is no perfect solution here as the enum value could be a map, tuple, unit, etc. However, given that we're trying to deserialize arbitrary values, deserializing as a "newtype" actually makes a lot of sense:
EnumAccess::newtype_variant_seed
.Deserialize
) should "just work" as expected because maps, tuples, etc. are preserved.If you're interested in this change, I can add some tests. Unfortunately, the token test logic never calls
visit_enum
fromdeserialize_any
, so testing will either require implementing a customDeserializer
and/or modifying the token deserializer.