Open taorepoara opened 2 months ago
If introduce new attribute it would be better do the following:
Composite
. Actually, two traits would be required, one for serialization and one for deserialization, because only serialization or only deserialization can be implemented by a type, CompositeDeserialize
and CompositeSerialize
.Composite*
bound to the corresponding types
There is many issues around the
flatten
field attribute: https://github.com/serde-rs/serde/issues?q=is%3Aissue+is%3Aopen+flattenI think that adding a strict mode to that attribute could be a good way to solve at least some of them.
I see many way to define the strict mode:
-F flatten_strict
. I think it's not the best solution since it would change the flatten for the whole project.#[serde(flatten = "strict")]
or#[serde(flatten = true)]
#[serde(flatten_strict)]
The strict flatten behavior would first parse the flattened fields one by one, removing the managed fields of the nested struct form the parsed data and ignoring the
deny_unknown_fields
on those struct. The parsing would be the same as not flatten struct so it would probably solve many issues.Then the main struct remaining fields would be parsed thanks to the remaining data fields. This way the
deny_unknown_fields
would work on the main struct.