Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Struct with named fields can be deserialized from sequence #206

Open
ghost opened this issue Jul 27, 2019 · 2 comments
Open

Struct with named fields can be deserialized from sequence #206

ghost opened this issue Jul 27, 2019 · 2 comments

Comments

@ghost
Copy link

ghost commented Jul 27, 2019

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:

use serde_derive::Deserialize;

#[derive(Debug, Deserialize)]
struct Person {
    first_name: String,
    last_name: String,
}

fn main() {
    let data = rmp_serde::to_vec(&("John", "Doe")).unwrap();
    eprintln!("{:?}", data);
    eprintln!("{:#?}", rmp_serde::from_slice::<Person>(&data));
}
@daboross
Copy link
Collaborator

daboross commented Aug 1, 2019

which is usually not what is wanted

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.

@josephg
Copy link

josephg commented Nov 12, 2019

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:

#[derive(Debug, Deserialize)]
#[rmp_serde(map)]
struct Person {
    #[serde(rename("firstName"))]
    first_name: String,
    last_name: String,
}

Then it would be really easy to mix & match tuples and map based structs across an application as needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants