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

Premium typed arguments support #1506

Closed
ColinPitrat opened this issue Jun 23, 2019 · 4 comments
Closed

Premium typed arguments support #1506

ColinPitrat opened this issue Jun 23, 2019 · 4 comments
Labels
A-validators Area: ArgMatches validation logi

Comments

@ColinPitrat
Copy link

One of the main features I'd expect from clap is to be able to specify the type of an argument, typically int, and have it provide an helpful error message is the argument cannot be parsed properly.

Currently, either one has to parse the argument string and provide an error message or move the logic to a custom validator that tries to parse and display a helpful message if it fails, but still need to parse after that (but can unwrap() as the validator already ensure the value is convertible).

I see two main options to do that:

  • provide "standard" generic validators like is_type() or is_type_between(min: T, max: T). Then the user still has to parse but can be sure it will succeed (so unwrap()) and knows, if needed, some value checks have been done already
  • provide a new type() method to the builder. The args would be checked in a similar ways as validator do (to provide a helpful message) but on top of that, a generic typed_value_of method would return the arg with the proper type provided. It would panic if the type T is not the same as the one provided for the argument.

Ideally this would also cover flags like enum, vectors (e.g comma separated) as long as the proper trait is provided (typically TryFrom/TryInto) etc...

What do you think?

@ColinPitrat
Copy link
Author

Currently, what I do when I need this:

fn is_type<T: FromStr>(val: String) -> Result<(), String>
where <T as std::str::FromStr>::Err : std::string::ToString
{
    match val.parse::<T>() {
        Ok(_) => Ok(()),
        Err(m) => Err(m.to_string()),
    }
}

Used like this:

        .arg(Arg::with_name("some_uint")
                .required(true)
                (...)
                .validator(is_type::<u32>))
(...)

    let some_uint = match matches.value_of("some_uint").parse::<u32>().unwrap();

@omarabid
Copy link

I know it doesn't solve your problem but: https://github.com/clap-rs/clap_derive/issues/4

I think it's better to get the CustomDerive done by now. It could enable a bunch of stuff: Like handling configuration through clap-rs

@pksunkara pksunkara added A-derive Area: #[derive]` macro API and removed clap-derive-related labels Feb 3, 2020
@pksunkara
Copy link
Member

You should be able to achieve this with clap_derive now. For normal clap use, this issue about feature request to add some helpers.

@pksunkara pksunkara added A-validators Area: ArgMatches validation logi D: medium and removed A-derive Area: #[derive]` macro API labels Apr 9, 2020
@epage
Copy link
Member

epage commented Nov 4, 2021

Didn't know we had this issue. We've started requirements gathering and high level design of this at #2683 which we are hoping to implement for clap 4.

Closing this out in favor of #2683

@epage epage closed this as completed Nov 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-validators Area: ArgMatches validation logi
Projects
None yet
Development

No branches or pull requests

5 participants