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
This example is derived from some experimentation I do at the moment.
It creates three different struct layouts and tries to deserialize the same test data into it.
If you run the tests you will see that the test data_3 (which deserilized into Data3 struct) fails because of the number deserialization issue.
For a better visibility here are the three structs:
All three tests in this sample setup use the same struct: FieldData for the fields and the deserializer has no issues with it in the data_1 and data_2 tests.
Okay so, the issue here is that the ini data is untyped, all values are strings. This deserializer tries to use FromStr when needed as a convenience, so that deserialize_with isn't necessary to use for anything that's not a string type. However, serde's flatten collects all extra fields until the end of deserializing (as typed strings), then uses its own Deserializer to convert that to the HashMap<Keys, FieldData> which does not use the same conversion magic - this results in the inconsistency.
Perhaps @dtolnay could chime in on how best to approach this. Removing the conversions and requiring deserialize_with="from_str" on everything would be more consistent and explicit. This seems like an annoying and unnecessary burden for the majority of use cases, but perhaps the conversions are too magic to be something a deserializer should be doing?
For now I would recommend keeping the type conversions in serde_ini but using a #[serde(with = "...")] attribute on non-string fields that get flattened, in this case size. The implementation in serde_with::rust::display_fromstr should do the trick.
https://github.com/Larusso/serde-ini-fail-example/blob/master/src/lib.rs
This example is derived from some experimentation I do at the moment.
It creates three different struct layouts and tries to deserialize the same test data into it.
If you run the tests you will see that the test
data_3
(which deserilized intoData3
struct) fails because of the number deserialization issue.For a better visibility here are the three structs:
All three tests in this sample setup use the same struct:
FieldData
for the fields and the deserializer has no issues with it in thedata_1
anddata_2
tests.I hope this helps you
Originally posted by @Larusso in #5 (comment)
The text was updated successfully, but these errors were encountered: