Name duplicate option value

[bjeanes]

I am using clap_derive with an option like:

struct Opts {
    // other fields elided

    #[clap(short = "F", long, name = "FROM_URL", validator = is_http_url, env = "SYNC_JACKETT_URL"")]
    from: Option<Url>,

    #[clap(short = "T", long, name = "TO_URL", validator = is_http_url, env = "SYNC_JACKETT_URL")]
    to: Option<Url>,
}

I had tried to give name = "URL" for both so that the help and usage is tidier here, but the macro gives a warning that the names must be unique.

I don't quite understand why this is a requirement (in this case). As far as I can tell, the name is not used (publicly) to disambiguate anything. The value is stored in different options.

If I put name before long and do not override long's value, then it inherits from name and I can definitely see why it must be unique in that case, but when the struct field, short name, long name, etc is provided and is unique, is it possible to use the same value name?

Another place this has come up is with multiple options that take a duration as an argument. For instance, you might have --connect-timeout=SECS, --read-timeout=SECS etc.

It isn't useful from a docs perspective to name each one of these differently and it is actually less clear to not name them at all so that there is --connect-timeout=<connect-timeout>. The SECS is a relatively clear short hand that tells the user the units they need to provide, for example.

[CreepySkeleton]

The more I think about this, the more I'm assured that clap uses wrong terminology here. You see, the string you pass to Arg::new() constructor (#[clap(name = "...")] attr) isn't exactly the name of the argument but rather identifier. Due to the way arguments are stored and processed, this identifier MUST be unique at all times. This is basically an invariant that must be upheld. I'm actually writing "clap book" that will cover this topic.

Help/error messages is a different topic. How clap decides what to print in -F <WHAT??>? Most of the time, it uses the identifier because this is the most common case: the string you pass into Arg::new is very likely the fitting name for the value. But sometimes it's not the case, and this is why Arg::value_name and Arg::value_names exist. They override the name of the value, former for sngle value args, latter for multiple values. You should use them.

[bjeanes]

Can value_name be used with clap_derive? I tried to find something like this but came up empty (though I may very well have just missed the example).

[bjeanes]

Yes, yes you can set value_name = "URL". Awesome.

Thank you!