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

Support for adding a validator on a #[derive(Args)] struct #3633

Closed
2 tasks done
nipunn1313 opened this issue Apr 15, 2022 · 2 comments
Closed
2 tasks done

Support for adding a validator on a #[derive(Args)] struct #3633

nipunn1313 opened this issue Apr 15, 2022 · 2 comments
Labels
C-enhancement Category: Raise on the bar on expectations

Comments

@nipunn1313
Copy link

Please complete the following tasks

Clap Version

3.1.3

Describe your use case

Given something like this (toy example)

#[derive(clap::Args)]
struct NameSelector {
    /// One or more names
    names: Vec<String>,
}

It might be nice to be able to achieve something similar to the Arg validator , but for the whole struct.

May be particularly useful if NameSelector grows more complex and/or reused in multiple CLI commands.

Describe the solution you'd like

// proposed idea

#[derive(clap::Args)]
#[clap(validator(name_validator))]
struct NameSelector {
    /// One or more names
    names: Vec<String>,
}

fn name_validator(v: &NameSelector) -> Result<(), String> {
    if v.names.contains("Hitler") {
        return Err("We don't like Hitler");
    }
    Ok(())
}

Alternatives, if applicable

Alternate interface could be a trait that you impl on NameSelector - but that doesn't seem in the spirit of the existing validator implementation.

Additional Context

No response

@nipunn1313 nipunn1313 added the C-enhancement Category: Raise on the bar on expectations label Apr 15, 2022
@epage
Copy link
Member

epage commented Apr 15, 2022

We are looking at generalizing our validation logic so that its both optional and so users can provide their own. We are tracking this work in #3008 though it will be working at the builder level rather than at the derive level.

@epage epage closed this as completed Apr 15, 2022
@nipunn1313
Copy link
Author

Cool. Thanks for the explanation. #3008 sounds challenging, but great. Looking forward to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: Raise on the bar on expectations
Projects
None yet
Development

No branches or pull requests

2 participants