Allow boolean literals as values for flags

[emilk]

The behavior of --flag=false setting the flag to the value true has caused problems for me many times. The problem is that boolean arguments are treated differently than arguments of other types.

As an example, say you have a few arguments to your program being called from someplace like so:

my_app --name=${name} --age=${age} --alive=${alive}

The first two will work as expected, but the third will be a bug with no error or warning message. This special case for the boolean type is very annoying. I would advocate a more orthogonal design.

Here is my suggestion for how to parse boolean flags:

Argument	Flag value
empty	false
--flag	true
--flag=true	true
--flag=false	false
--flag=other	Helpful error message

The problem with this comes when considering how to treat other potential ways to express boolean, e.g. 0/1, no/yes, False/True. We could add these as well to the above table, or stick to the Rust convention (true/false). Either way would work for me.

In summary: the principle of least surprise suggests that if --int=42 should work the same as --bool=false.

[TeXitoi]

TeXitoi/structopt#212 (comment)

[CreepySkeleton]

@emilk Could you please provide an exact snippet of code you're having the problem with? Along with expected/actual behavior.

[pksunkara]

Possible solution is to have a setting which allows flags to also allow boolean literals as values.

[colemickens]

If there's a workaround someone could share, that would be great (I was wondering if maybe it's possible with the builder, or a custom parser? It seems like structopt has a way, but I can't find such functionality in clap at first glance).

To elaborate on justification for this bug... It is more than just surprising behavior. From what I can tell, it actively prevents certain designs. For example, I have a flag that really should be on by default (--create-users) and I don't want a --dont-create-users flag, I really want the user to have to say --create-users=false if they are expert enough to opt-out.

[CreepySkeleton]

You couldn't find this functionality because it doesn't exist.

The key is that flags do not take value in clap, period. Flags that take value are called options. Options can be either present (possibly with a number of values following) or not. There's no notion of "if this option has one value and the value equals false then pretend that the option wasn't present".

structopt can do it because it applies postprocessing - conversion - to the values, and what you observe is result of the conversion. It doesn't change the fact that the option was actually present. You can simulate it with

// create an option with optional value
Arg::new("pseudo-flag")
    .possible_values(&["true", "false"])
    .long("foo")
    .min_values(0)
    .max_values(1)
    
/// ...

let setting = app.value_of("pseudo-flag") != Some("false");

[colemickens]

Thank you for the detailed explanation @CreepySkeleton, I hadn't quite understood the important distinction between "options" and "flags". It turns out, this also works, since I prefer explicit boolean options over "flags" -- https://github.com/clap-rs/clap/blob/dd5e6b23131f16ef8b090a8482f1b97c6a693498/clap_derive/examples/true_or_false.rs