[Question] Dynamic Flags

[sergeyklay]

Hi!

This is not a issue, but more a question. I'm sorry if I chose the wrong place to ask questions. Is it possible to create dynamic flags, if yes, could you please provide a small example of parsing and using such a flags.

Desired format:

$ app --help
app 1.0.0

USAGE:
    app [FLAGS] [SUBCOMMAND]

FLAGS:
        -fno-([a-z0-9\-]+)    Disables compiler optimizations
        -f([a-z0-9\-]+)       Enables compiler optimizations
        -W([a-z0-9\-]+)       Turns a warning off
        -w([a-z0-9\-]+)       Turns a warning on
    -h, --help                Prints help information
    -V, --version             Prints version information

SUBCOMMANDS:
    generate     ...

Thus, for example, user will able to use app as follows:

app -Wimplicit-int -Winvalid-pp-token generate

Note: Here is one - and each flag definition provided in regexp form.

Thank you

[kbknapp]

This is fine for questions, I welcome them anywhere 😄

What you're looking for is supported as what clap calls options. Minus -fno-([..]) which isn't supported exactly, but a sort of workaround exists.

If you make an option with only a short, it'll work exactly like you're looking for

app
.arg(Arg::from_usage("-f [optimization]    'Enables compiler optimizations'"))
.arg(Arg::from_usage("-W [warning]         'Turns a warning off'"))
.arg(Arg::from_usage("-w [warning]         'Turns a warning on'"))

Then one could also add a Arg::validator which checks the value against a regex.

Could be run as $ prog -Wimplicit-int just fine.

Once I get to a computer (I'm on mobile) I can explain the -fno- portion and how to use the workaround or potentially adding support for such.

[sergeyklay]

Looks really nice. Thank you very much! The last think I need is -fno-.

[kbknapp]

Sorry it took me so long I got home late.

Right now, when clap encounters a single hyphen it looks so see if the next character is a flag or an option. If it's a flag, it then looks at the next character to see if it's also a flag, and so on and so forth. As soon as it encounters an option, it looks at the next character and begins parsing the value.

In the case of -fno- clap will see -f is a valid option, and parse everything else as a value. Now in your validator, or in the user code that collects the values, you could just say "everything that starts with no- would be the same as coming from -fno- which would only require changing the help message.

.arg(Arg::from_usage("-f [optimization]    'Enables compiler optimizations (or disables if they start with \'no-\''"))

So that's the "workaround" but I understand that may be less than ideal.

So I've also been toying with the idea of adding an AppSettings variant that allows X toolkit style flags and options (such as find with -delete or -name, etc.). This would allow one to declare -fno- in cooperation with the above args and achieve the desired result.

The downside to using this new setting, it would disable the ability to "stack" flags (such as using -FzBod being equivalent to -F -z -B -o -d). But if that's unimportant to your use case, it would be a moot tradeoff.

[sergeyklay]

In fact, I wouldn't want you to change design of this awesome library. Do not worry. I will play with the capital -F. 👍

[kbknapp]

It wouldn't be changing the design, that's the purpose of the AppSettings enum, to tweak behavior as an opt in feature 😉