Before #2005, `Clap` was a special trait that derived all clap traits it
detected were relevant (including an enum getting both `ArgEnum`,
`Clap`, and `Subcommand`). Now, we have elevated `Clap`, `Args`,
`Subcommand`, and `ArgEnum` to be user facing but the name `Clap` isn't
very descriptive.
This also helps further clarify the relationships so a crate providing
an item to be `#[clap(flatten)]` or `#[clap(subcommand)]` is more likely
to choose the needed trait to derive.
Also, my proposed fix fo #2785 includes making `App` attributes almost
exclusively for `Clap`. Clarifying the names/roles will help
communicate this.
For prior discussion, see #2583
It turns out `value_name` appends, so by setting an implicit and
explicit `value_name`, the user gets both and `num_vals=2`.
There is still a question on `value_name` and whether its documentation
or behavior needs updating. If that changes, then this can be
simplified by reverting back.
Fixes#2632
I debated putting this fix inside of the Builder API but I figure this
makes it so you "pay for what you use", with the derive API giving it to
you "for free".
A potential next step is to improve the default value name. I tend to
use value_name to hint at how to use an argument, which correlates with
types. We could add a
`ValueName::value_name(fallback: &str) -> &str` with impls for common
types, so we get more of a usage-based result.
Fixes#2608
