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
Serde Msgpack unlike other format implementations has an option to the serializer to tell whether to serialize structs as a map with named fields or as a sequence without field names. The deserializer doesn't however have the corresponding option, but instead relies on this issue to accept both forms, which is usually not what is wanted, and comes with the unwanted consequences mentioned in the issue in Serde. Either the deserializer should have this option added, or even better, remove the option from the serializer and let the serialize implementation of the struct decide the format. The correct way to specify that a struct is going to be serialized without field names is in the serialize implementation of the struct. A container attribute can be added to Serde Derive for this purpose.
Example code adapted to Serde Msgpack:
use serde_derive::Deserialize;#[derive(Debug,Deserialize)]structPerson{first_name:String,last_name:String,}fnmain(){let data = rmp_serde::to_vec(&("John","Doe")).unwrap();eprintln!("{:?}", data);eprintln!("{:#?}", rmp_serde::from_slice::<Person>(&data));}
The text was updated successfully, but these errors were encountered:
Just speaking as another user, there are definitely use cases for loosely-validated deserialization. My use case isn't every use case of course, but being able to recover badly-serialized data can be more valuable than strict validation if fixing the application serializing stuff is out of the picture.
Personally I find it weird that you decide when you serialize whether you want to encode struct values as tuples or maps. Seems like it would be much more consistent to do it on a struct-by-struct basis with macros. Eg:
This issue in Serde affects Serde Msgpack.
Serde Msgpack unlike other format implementations has an option to the serializer to tell whether to serialize structs as a map with named fields or as a sequence without field names. The deserializer doesn't however have the corresponding option, but instead relies on this issue to accept both forms, which is usually not what is wanted, and comes with the unwanted consequences mentioned in the issue in Serde. Either the deserializer should have this option added, or even better, remove the option from the serializer and let the serialize implementation of the struct decide the format. The correct way to specify that a struct is going to be serialized without field names is in the serialize implementation of the struct. A container attribute can be added to Serde Derive for this purpose.
Example code adapted to Serde Msgpack:
The text was updated successfully, but these errors were encountered: