As discussed on Discord, I believe the dynamic.optional_field behaviour is a bit off and this PR tries to adjust it to match the documented behaviour.
The use of decode_optional in the implementation meant that the value was optional as well as the key which means that each use of optional_field was implicitly wrapping its value decoder in dynamic.optional.
Awkwardly this is a breaking change in behaviour but not in types. We can now get Some(None) back which I don't think was previously possible and we get an error in situations where we didn't before.
I'm not sure if the per-target tests is how you like to manage that situation.
As discussed on Discord, I believe the
dynamic.optional_fieldbehaviour is a bit off and this PR tries to adjust it to match the documented behaviour.The use of
decode_optionalin the implementation meant that the value was optional as well as the key which means that each use ofoptional_fieldwas implicitly wrapping its value decoder indynamic.optional.Awkwardly this is a breaking change in behaviour but not in types. We can now get
Some(None)back which I don't think was previously possible and we get an error in situations where we didn't before.I'm not sure if the per-target tests is how you like to manage that situation.