clap 3.2: How to get equivalent of possible_values with conversion to field type?

[kpreid]

clap 3.2 deprecated #[clap(possible_values = ...)]. The suggested replacement is value_parser = PossibleValuesParser::new([...]). But this seems to be not the whole solution, because using possible_values will allow converting the string to the type of the field, whereas dropping in PossibleValuesParser produes a run-time type mismatch error. Specifically:

use clap::Parser;

/// This enum is not defined in the crate doing the parsing and should not depend on clap
#[derive(Clone, Debug)]
pub enum Template {
    Foo,
}
impl Template {
    const NAMES: &'static [&'static str] = &["foo"];
}
impl std::str::FromStr for Template {
    type Err = &'static str;
    fn from_str(s: &str) -> Result<Self, Self::Err> {
        match s {
            "foo" => Ok(Self::Foo),
            _ => Err("Unrecognized"),
        }
    }
}

#[derive(Clone, Debug, Parser)]
pub(crate) struct Args {
    #[clap(
        long = "template",
        default_value = "foo",
        // possible_values = Template::NAMES,                                    // this works
        value_parser = clap::builder::PossibleValuesParser::new(Template::NAMES) // this fails
    )]
    pub(crate) template: Template,
}

#[test]
fn test() {
    Args::parse_from(["app", "--template", "foo"]);
}

This program fails with

thread 'clap32::test' panicked at 'Mismatch between definition and access of `template`. Could not downcast to scratchpad::clap32::Template, need to downcast to alloc::string::String

What is the correct equivalent of possible_values here?

[epage]

Yes, PossibleValuesParser only provides a String output type at this time.

In another thread, I gave this reply

The new design presupposes the field type when using possible values is a String. In the short term, you would need to write your own TypedValueParser and do #[clap(value_parser = LevelFilterValueParser)]. See PossibleValuesParser for inspiration. I'd also say feel free to open an issue requesting native support for this. I held off on natively supporting this because I was unsure how much it would be needed and what the combination of needs would be (would FromStr be sufficient or would it need to compose with another TypedValueParser, etc).

I would say in your case, you could derive ValueEnum (formerly ArgEnum) on Template and clap will automatically handle the possible values, parsing, etc.

[kpreid]

I would say in your case, you could derive ValueEnum (formerly ArgEnum) on Template.

No, because Template is in another library crate which does not and should not depend on clap — it defines a string representation for all its values, but is not in the business of command-line UI in particular.

It's entirely reasonable to define a custom parser for unusual needs; I asked about this situation because it specifically appeared to be a regression and I wanted to know if I was missing something.

[sunshowers]

I ran into the same issue, and the solution I came up with was (assuming variants and from_str methods):

value_parser = PossibleValuesParser::new(MyType::variants()).map(|s| MyType::from_str(&s).unwrap())

Like kpreid above, my type was also in a library crate that didn't depend on clap. However, I ended up solving this by making a duplicate type in the application crate and writing a From implementation from the application type to the library type.

[epage]

Yes, TypedValueParser::map is a great solution for this. I added it for another use case and only late realized it helps here. I backported it to clap 3.

Like kpreid above, my type was also in a library crate that didn't depend on clap. However, I ended up solving this by making a duplicate type in the application crate and writing a From implementation from the application type to the library type.

With map, why do you still need a newtype?

[sunshowers]

It wasn't necessary, but ended up being cleaner overall. (In particular, CLI parsing was the only reason the variants method and the FromStr impl were required, so removing them reduced the net loc.)