Open andrewtoth opened 5 months ago
The tests fail due to trybuild
using an older version of serde
or serde_derive
. This PR only modifies API in the private
mod, and in serde_derive
. However, if after this patch both serde
and serde_derive
are not upgraded in lockstep then this will break at compile time. I'm not completely sure then, if this can be considered a non-breaking change? If all packages using serde
and serde_derive
in a project upgrade in lockstep then there is no external breaking change. Is it a requirement that serde_derive
and serde
be backwards compatible with older versions of each other?
@Mingun thank you for your review and suggestions! I implemented them both. As for tests, I will happily write them but first could you confirm that the approach here will be accepted?
I don't know, I am the same external contributor as you. Judging by the general reaction of maintainers, one should hardly expect any attention in the near future
It is interesting that I went on to try to solve another problem revolving flatten in #2751 and we actually ended up on very similar approach.
This adds a custom error type for
FlatMapDeserializer
, which distinguishes the specificno variant of enum {name} found in flattened data
error.This error is then used in
deserialize_map
inserde_derive
tomatch
on the returned error, and if the field or container has adefault
attribute it uses theexpr_is_missing
to provide a default value.Fixes https://github.com/serde-rs/serde/issues/1626