Is parsing more complex in Clap 3.2?

[steveklabnik]

I'm working through an upgrade to 3.2, which I generally think is going in a great direction. It's not totally clear to me how to upgrade some code like this, though:

    /// specifies an I2C controller
    #[clap(long, short, value_name = "controller",
        parse(try_from_str = parse_int::parse),
    )]
    controller: Option<u8>,

I think, from reading the derive reference, that this code should be using value_parser instead. Is that correct?

I was trying to figure it out, and got this, which doesn't work

    #[clap(long, short, value_name = "controller",
        value_parser(clap::builder::ValueParser::new(parse_int::parse)),
    )]
    controller: Option<u8>,

by saying type annotations are needed. And now I feel a bit stuck. I don't have a novel type here, just an Option<u8>. We're using https://crates.io/crates/parse_int to accept various prefixes on strings that are useful. Would I really have to newtype Option here to accomplish this?

[epage]

Yes, that should be using value_parser. It seems a downside to the new approach is the u8 isn't showing up anywhere for inference to determine the type for parse_int, so you need the turbo fish. Unfortunately,. I don't think there is a way to get type inference working.

Working example:

#!/usr/bin/env -S rust-script --debug

//! ```cargo
//! [dependencies]
//! clap = { path = "../clap", features = ["derive"] }
//! parse_int = "*"
//! ```

use clap::{Args, Parser, Subcommand};
use std::path;

#[derive(Debug, Parser)]
struct Cli {
    #[clap(
        long,
        short,
        value_name = "controller",
        value_parser = parse_int::parse::<u8>
    )]
    controller: Option<u8>,
}

fn main() {
    let cli = Cli::parse();
    dbg!(cli);
}

[steveklabnik]

Ah ha! Thank you!

I'm not super concerned about the turbofish; I was just thinking "dang this is way more verbose" and if I had to implement a custom parser, that'd be even more so, but this is just as easy as the older way. Thank you so much! 🙏

[epage]

if I had to implement a custom parser, that'd be even more so

If you find yourself implementing TypedValueParser, I'd be interested in hearing the use case in case there is a way we can improve things. Though if its for a custom type, you can also implemented ValueParserFactory and you won't have to set the value_parser attribute, it'll be picked up automatically.

this is just as easy as the older way.

Sometimes making things easy backfires on me but hopefully it doesn't in this case. This involves

• auto-deref specialization when no value_parser value is specified (which is what picks up ValueParserFactory types)
• a ValueParser::from on the attribute value that accepts
  • a try_from_str
  • Possible values like ["always", "auto", "never"]
  • numeric ranges (30..40)
  • an instance of impl TypedValueParser