Open pickfire opened 3 years ago
Agreed on not being in v3
Structopt
passes cased_name
to Arg::with_name
, so I think its "broken" there too. So by leaving this, we don't introduce any more of a migration problem than if we change it now.
I am not exactly sure what the expected behaviour should be.
I am not exactly sure what the expected behaviour should be.
As a user solely of clap_derive
, I do not know of the existence of the "name" field, just what my variables are. I have a variable named hello_world
, I assume when working with conflicts_with
, I would pass in that variable name.
With #3453, I expect rename_all
for args will change the value_name and not what is passed to Arg::new
Needing to re-think this
rename_all
:
id
, long
, and short
rename_all
, we already apply a default casing for id
, long
, and short
name
which serves as both the user value and the idname
So what is
rename_all
rename_all
For example, this issue talks about the id
becoming morphed but the equivalent of the id for subcommands can't be passed up. If we do this, then it will be inconsistent.
rename_all
is generally meant to workaround the language's casing from mismatching with the problem domain so from that perspective, renaming the id
can make sense since its happening before it gets to the problem domain.
short casing can be handled naiively (verbatim) but since long casing has to change anyways, we need a way to control that, right?
value name seems the most likely to need a rename_all
because its pretty split between SCREAMING_CASE and kebab-case.
With this level of uncertainty, I'm going to hold off for now.
Maintainer's notes:
With #3335 resolved, the remaining work is
Apply renames to
value_name
and notid
Please complete the following tasks
[X] I have searched the discussions
[X] I have searched the existing issues
Rust Version
rustc 1.52.0 (88f19c6da 2021-05-03)
Clap Version
3.0.0-beta.2
Minimal reproducible code
It is a bit confusing that conflicts_with only work with the transformed string and the issue is that it only errors on runtime, during compile-time there is no error saying that that is incorrect. Can it be checked during compile-time? It is also confusing that I put
hello_world
in the struct but I need to usehello-world
in the option.Steps to reproduce the bug with the above code
cargo run
Actual Behaviour
Expected Behaviour
First, using
hello_world
should work instead ofhello-world
.Second, it should error during compile-time.
Additional Context
No response
Debug Output