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

Externally tagged enum variants where all fields have #[serde(default)] should allow being written as a unit variant. #2691

Open
Scripter17 opened this issue Feb 6, 2024 · 3 comments

Comments

@Scripter17
Copy link

I'm building a program that takes URLs and strips all the tracking parameters and handles redirects and so on. One of the mappers is ExpandShortLink, which just sends a request to the URL being cleaned and returns the URL the server responded with.

I'm trying to support the case where a user wants to specify HTTP headers for a specific ExpandShortLink without requiring that all uses of ExpandShortLink have a default header map (I expect it to be a niche feature).

Basically, I have this code:

use serde::Deserialize;
use serde_json::from_str;
use std::collections::HashMap;

#[derive(Deserialize)]
struct Rule {
    // ...
    mapper: Mapper
}

#[derive(Deserialize)]
enum Mapper {
    // ...
    ExpandShortLink {
        #[serde(default)]
        headers: HashMap<String, String>
    }
}

fn main() {
    assert!(from_str::<Rule>("{\"mapper\": {\"ExpandShortLink\": {\"headers\": {}}}}").is_ok());
    assert!(from_str::<Rule>("{\"mapper\": \"ExpandShortLink\"}").is_ok());
}

I would like to have {"mapper": "ExpandShortLink"} and {"mapper": {"ExpandShortLink": {"headers": {}}}} both deserialize to Rule {mapper: Mapper::ExpandShortLink {headers: HashMap::new()}}.

@Scripter17
Copy link
Author

Great so if I go to a different issue on github mobile and close it it has a chance of closing a random issue

Got it

Great

@Scripter17 Scripter17 reopened this Feb 17, 2024
@iTitus
Copy link

iTitus commented May 4, 2024

Related to #2233 #2508 #2706
Will this get fixed by #2509 or #2520? #2295 also looks promising.

@Scripter17
Copy link
Author

The first and third PRs would definitely fix this. I'm not quite awake enough to make heads or tails of the second one but it seems to also handle this.

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