num_vals is now constructed from val_names in only one place instead of two
#2693
Conversation
|
Could you expand on what is intending to be fixed in the interaction? |
|
It's about how |
|
Ok, so this is about single-sourcing the construction. |
|
Yup |
|
Could you update the PR title / description to reflect that? It helps a lot when coming up to speed on a code base. I've dug through a lot of old PRs from a variety of people and the lack of detail has made it hard for me to undetstand the motivation for a change. |
pksunkara
changed the title
num_vals is now constructed from val_names in only one place instead of two
| fn number_of_values_preferred_over_value_names() { | ||
| let m = App::new("test") | ||
| .arg( | ||
| Arg::new("pos") | ||
| .long("pos") | ||
| .number_of_values(4) | ||
| .value_names(&["who", "what", "why"]), | ||
| ) | ||
| .try_get_matches_from(vec!["myprog", "--pos", "val1", "val2", "val3", "val4"]); | ||
|
|
||
| assert!(m.is_ok(), "{:?}", m.unwrap_err().kind); |
There was a problem hiding this comment.
Should this be an error case?
I've seen 1 value_name be repeated for all num_vals and I've seen N value_names for N num_vals. I'm wondering what the use case is for more value_names or what we usage when there are 1 < value_names < num_vals
There was a problem hiding this comment.
number_of_values should be given preference which is why this is not an error case. value_names can diverge away from number_of_values, but that is a matter for us to decide on how the help output should be rendered. We currently handle some cases but not all of them.
There was a problem hiding this comment.
I think the most likely case for a mismatch, besides 1:M is the user missed one and that a debug assert would be the best course of action. Probably not worth deciding in this. I'll go create an issue.
No description provided.