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
Positional bool panics #5135
Comments
The relevant piece of documentation is the arg types. What you need to do is override the implicit
Closing in favor of #4467 which is tracking this. |
Ah alright, thanks for the quick and precise response. Yeah, While I am satisfied with all the infos now, I still fear that more people could fall into this trap and especially with a rare thing such as positional bools easily assume this runtime warning is an actual bug and report it. Would it maybe make sense to add a hint regarding the arg types to the assert message here? Or does it handle to many other cases as well for this to be too specific? |
Good idea. #5136 is at least a slight improvement |
Please complete the following tasks
Rust Version
stable-x86_64-unknown-linux-gnu unchanged - rustc 1.72.0 (5680fa18f 2023-08-23)
Clap Version
clap v4.4.4 and clap_derive 4.4.2
Minimal reproducible code
Steps to reproduce the bug with the above code
cargo run
panics whilecargo build
does not complain about anything.Actual Behaviour
Expected Behaviour
Ideally this should work as if
enabled
were some other type likei64
for example, or this should already fail on compilation rather than during runtime.Additional Context
I'm working on a CLI client that has the command
user tfa <id> <enabled>
to either enable or disable TFA for a user. Due to this panic this is not possible however, or at least not with a positional bool.Or is there any more argument for the attribute needed to accomplish this?
Debug Output
With debug and backtrace:
The text was updated successfully, but these errors were encountered: