Fix newtype variant unwrapping inside enum, seq and map #331
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 is a follow-up to #319 which added the
unwrap_variant_newtypes
extension.Unfortunately, it seems like I missed a few interactions with parsing enums, sequences and maps nested inside a newtype variant (i.e. not inside a containing non-newtype struct). I have fixed all three and added extra test cases to cover their intended functionality, i.e.
NewtypeVariant( [ Struct(...) ] )
,NewtypeVariant( { "key": Struct(...) } )
, andNewtypeVariant( StructVariant(...) )
all parse again.Discussion
Option<T>
is another fun case. Here I think carrying through the unwrapping actually is quite neat, but I want to get your input if this should be the intended behaviour:NewtypeVariant( None )
NewtypeVariant( Some(a: 4, bool: false) )
forOption<Struct>
andstruct Struct { a: u32, b: bool }
NewtypeVariant( a: 4, bool: false )
is theimplicit_some
extension is switched on as wellI am also a bit unsure about how to handle
deserialize_any
. I think I may need your help with that one.TODO
CHANGELOG.md