Ability to infer arguments which are enum strings

[crazyscot]

I have an option that allows users to select one of a few variants. The set of allowed values is an enum; it does not make sense for it to be a subcommand.

I would like the user to be able to abbreviate the values in this enum, in the same way as infer_subcommands.

Have I missed something? Evidently the engine is doing a prefix-match to generate this output...

$ ./target/debug/argz -t f
error: invalid value 'f' for '--thing <THING>'
  [possible values: foo, bar]

  tip: a similar value exists: 'foo'

Source code for this example:

use clap::{Parser, Subcommand, ValueEnum};
use strum_macros::EnumString;

#[derive(ValueEnum, Debug, Clone, Subcommand, EnumString)]
enum Thing {
    Foo,
    Bar,
}

#[derive(Debug, Parser)]
struct Cli {
    #[arg(short, long)]
    // This is an argument, it cannot be a subcommand. Is there an equivalent of #[command(infer_subcommands = true)] ?
    thing: Thing,
}

fn main() {
    let cli = Cli::parse();
    println!("{:#?}", cli);
}

[epage]

We have infer_long_args and infer_subcommands. We do not have a infer_possible_values at this time (though we do have ignore_case).

Personally, I feel that infer_* is a compatibility hazard (add something new and existing muscle memory can fail due to ambiguity) and generally people don't need arbitrary abbreviations that I generally recommend people instead specify discrete aliases (e.g. cargo doesn't use this but has a cargo c alias).

If you still want it, feel free to create an issue. We can evaluate the interest in it and the impact. We are trying to balance the impact of a feature against bloating the API and negatively impacting build time / binary size.

[crazyscot]

Thanks. I could live with manual aliases; are they currently supported in this context?

[epage]

Yes, when using ValueEnum, you can set #[value(alias = "f")]. No one has implemented visible_alias at this time