Simplifying derive for generic structs without command(flatten)

[cardoso]

I have a list of subcommands, each for a different compression algorithm that accept a different type of level.

I was expecting something like this to work:

#[derive(Args)]
pub struct LevelArgs<T> {
    #[arg(long, short)]
    level: Option<T>,
    #[command(flatten)]
    common: CommonArgs,
}

However, lots of bounds are required to be explicit in order for the build to succeed, and annoyingly, they come up one at a time in rustc's error messages, so it takes a lot of trial and error to figure out.

#[derive(Args)]
pub struct LevelArgs<T: FromStr + Send + Sync + Clone + 'static> where T::Err: Error + Send + Sync + 'static {
    #[arg(long, short, value_parser=T::from_str)]
    level: Option<T>,
    #[command(flatten)]
    common: CommonArgs,
}

I can see most people giving up this approach. I did the first time. Also, without a way to alias all of these bounds the code is pretty ugly.

This is the usage site and it would ideally remain the same, but it could change if it helps avoid breaking changes:

#[derive(Parser)]
pub enum Cli {
    Uncompressed(CommonArgs),
    Snappy(CommonArgs),
    Gzip(LevelArgs<u8>),
    Lzo(CommonArgs),
    Brotli(LevelArgs<u32>),
    Zstd(LevelArgs<i32>),
    Lz4Raw(CommonArgs),
}

• Am I missing some feature clap already supports that improves this experience?
• Would it make sense for the Args derive to implicitly add most if not all of these trait and lifetime bounds?
• Would it make sense to implicitly add value_parser=T::from_str?
• Would it be a breaking change?

If it makes sense, I could submit a PR.

[epage]

There is not a clap feature to help with this. There is also not much clap can do. We'd need to auto-detect the type of value parser being used by textually analyzing the attribute and guess what bounds it needs. That is not a practical thing to do.