-
Notifications
You must be signed in to change notification settings - Fork 15
cli booleans avoid negatives #156
Comments
hmmm, now that I think about it, I'm not a massive fan of mixing "true clap flags" and "boolean clap flags". I'd prefer only "true clap flags", and you're saying the only way to do that is to go the |
You either have a boolean option, ehich can default to true, and they always need a value, and have no single letter flag (as value is required) Or clap flag which takes no value, defaults to false, and can have a single letter version. |
I've gone for explicit
|
At this point I think we've learned that using |
b5 wrote on #179
I agree and would like to make it work this way, but Clap doesn't do this out of the box, so I've created a separate issue to figure this out.
What works is this (where the flag defaults to true):
Note that this does not support
--metrics
by itself, only with explicit=true
and=false
. I think that's acceptable for flags that default totrue
.Documentation generated by Clap seems reasonable:
For flags that default to
false
we can use Clap's normal flag mechanism:Documentation is like this:
Note that this is a true Clap flag: it's only used to enable something, and you can't use an explicit
true
orfalse
.I wanted to highlight this difference, though I think it's acceptable. If we want to stick with true Clap flags for the "flag is turned on by default" use case, we have to take the
--no-
flags route instead.Relevant Clap issues & PRs
The general explicit flag story:
clap-rs/clap#1649
Automatic support for
--no
flags. Isn't implemented.clap-rs/clap#815
This misdirected me for a bit but has to do with environment variable parsing, so it not related:
clap-rs/clap#2664
The text was updated successfully, but these errors were encountered: