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

Take into account deny_unknown_fields attribute when deserialzie struct from sequence #2437

Closed
wants to merge 2 commits into from

Conversation

Mingun
Copy link
Contributor

@Mingun Mingun commented Apr 30, 2023

This PR expands scope of deny_unknown_fields container attribute to sequences, making behaviour consistent when struct deserialized from a map or from a sequence:

#[derive(Deserialize)]
struct A {
    number: i32,
    text: String,
}

could be deserialized from

{
    "number": 1234,
    "text": "hello",
    "dont": 345.234,
    "really": [],
    "care": true
}

and from

[
    1234,
    "hello",
    345.234,
    [],
    true
]

The

#[derive(Deserialize)]
#[serde(deny_unknown_fields)]
struct A {
    number: i32,
    text: String,
}

could be deserialized only from

{
    "number": 1234,
    "text": "hello"
}

and from

[
    1234,
    "hello"
]

Closes #2432

failures (6):
    regression::issue2432::deny_unknown_fields::seq
    regression::issue2432::deny_unknown_fields::tuple
    regression::issue2432::deny_unknown_fields::tuple_struct
    regression::issue2432::no_deny_unknown_fields::seq
    regression::issue2432::no_deny_unknown_fields::tuple
    regression::issue2432::no_deny_unknown_fields::tuple_struct
@Mingun Mingun mentioned this pull request May 3, 2023
Copy link
Member

@dtolnay dtolnay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

#[derive(Deserialize)]
struct A {
    number: i32,
    text: String,
}

...

could be deserialized from

[
    1234,
    "hello",
    345.234,
    [],
    true
]

It is not clear to me that this is desirable, or the behavior that most users would expect to get here from derived Deserialize impls by default.

I left a suggestion in #2432 (comment) -- I think I would prefer if this were pursued in a different library.

@dtolnay dtolnay closed this May 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

More permissive support for sequence -> struct deser
2 participants