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

skip_serializing_if not works when an enum variant is a tuple and the enum has #[serde(tag = "type", content = "value")] #2721

Open
nan01ab opened this issue Mar 29, 2024 · 1 comment

Comments

@nan01ab
Copy link

nan01ab commented Mar 29, 2024

Like this example, the enum has a serde derive #[serde(tag = "type", content = "value")], and skip_serializing_if of the second variant not works:

version: serde 1.0.197, serde_json 1.0.115

    #[derive(Debug, Serialize, Deserialize)]
    pub struct Foo(String, u64, #[serde(skip_serializing_if = "String::is_empty")] String);

    #[derive(Debug, Clone, Serialize, Deserialize)]
    #[serde(tag = "type", content = "value")]
    pub enum Bar {
        One { #[serde(skip_serializing_if = "String::is_empty")] value: String },

        // `skip_serializing_if` not works.
        Two(#[serde(skip_serializing_if = "String::is_empty")] String),

    }

    #[test]
    fn test_foo_bar() {
        let foo = Foo("hello".into(), 1, "".into());
        let json = serde_json::to_string(&foo)
            .expect("`to_string` should be ok");
        assert_eq!(&json, r#"["hello",1]"#); // skipped as expected

        let bar = Bar::One { value: "".into() };
        let json = serde_json::to_string(&bar)
            .expect("`to_string` should be ok");
        assert_eq!(&json, r#"{"type":"One","value":{}}"#); // skipped as expected


        let bar = Bar::Two("".into());
        let json = serde_json::to_string(&bar)
            .expect("`to_string` should be ok");
        assert_eq!(&json, r#"{"type":"Two"}"#); // assert failed, because json is `{"type":"Two","value":""}`
    }
@Mingun
Copy link
Contributor

Mingun commented Mar 29, 2024

Could you check if #2520 solves this case too?

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

No branches or pull requests

2 participants