-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
value_name
appends, rather than overrides
#2634
Comments
@pksunkara any opinion on whether this is a documentation or implementation bug? |
Docs say that the name is cosmetic. Not the function.
While most of the other methods just extend existing data, |
Instead they should behave like `default_value`/`default_values`. In implementingt this, I didn't see any reason to be using a `VecMap`. In fact, this helped simplify the code / make intent clearer. With this, we are also able to simplify the derive macro work from clap-rs#2633. Fixes clap-rs#2634 BREAKING CHANGE: `value_name`/`value_names` always overwrite, rather than append. We expect the impact to be minimal.
Instead they should behave like `default_value`/`default_values`. In implementingt this, I didn't see any reason to be using a `VecMap`. In fact, this helped simplify the code / make intent clearer. With this, we are also able to simplify the derive macro work from clap-rs#2633. Fixes clap-rs#2634 BREAKING CHANGE: `value_name`/`value_names` always overwrite, rather than append. We expect the impact to be minimal.
Instead they should behave like `default_value`/`default_values`. In implementingt this, I didn't see any reason to be using a `VecMap`. In fact, this helped simplify the code / make intent clearer. With this, we are also able to simplify the derive macro work from clap-rs#2633. Fixes clap-rs#2634 BREAKING CHANGE: `value_name`/`value_names` always overwrite, rather than append. We expect the impact to be minimal.
Instead they should behave like `default_value`/`default_values`. In implementingt this, I didn't see any reason to be using a `VecMap`. In fact, this helped simplify the code / make intent clearer. With this, we are also able to simplify the derive macro work from clap-rs#2633. Fixes clap-rs#2634 BREAKING CHANGE: `value_name`/`value_names` always overwrite, rather than append. We expect the impact to be minimal.
Instead they should behave like `default_value`/`default_values`. In implementingt this, I didn't see any reason to be using a `VecMap`. In fact, this helped simplify the code / make intent clearer. With this, we are also able to simplify the derive macro work from clap-rs#2633. Fixes clap-rs#2634 BREAKING CHANGE: `value_name`/`value_names` always overwrite, rather than append. We expect the impact to be minimal.
Please complete the following tasks
Rust Version
rustc 1.53.0 (53cb7b09b 2021-06-17)
Clap Version
3.0.0-beta.2
Minimal reproducible code
#[clap(
number_of_values = 1,
long = "using",
value_name = "pm",
value_name = "foo",
)]
using: Option,
Steps to reproduce the bug with the above code
Run it
Actual Behaviour
pm
andfoo
show up in--help
Expected Behaviour
Additional Context
Split out of #2632. Depending on what solution we go with #2633 could be simplified
There is a separate
value_names
that is documented for providing multiple. That also appendsThis is either a bug in the documentation or in the code.
Related: documentation also says
value_name
is cosmetic only butvalue_name
, under certain situations, impliesnumber_of_values
.Most of the time, people will not run into this. Its when programmatically creating an argument, like in the derive macro.
Debug Output
No response
The text was updated successfully, but these errors were encountered: