You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I 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:
as a feature: -F flatten_strict. I think it's not the best solution since it would change the flatten for the whole project.
as an attribute value: #[serde(flatten = "strict")] or #[serde(flatten = true)]
as a new attribute: #[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.
The text was updated successfully, but these errors were encountered:
If introduce new attribute it would be better do the following:
introduce new trait to mark types that can be flatten into other types. I thought for a long time about a suitable name and my last idea is 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.
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.The text was updated successfully, but these errors were encountered: