Clap: Support overrides_with("itself")

[ericbn]

Suppose I have defined these:

.arg(flag("foo").overrides_with("foo"))
.arg(flag("bar").overrides_with("bar").takes_value(true).possible_values(&["0", "1", "2"]))

I'd like to allow the options to be able to be defined multiple times, the last one overriding previous ones.

So a call with options --foo --foo --foo --bar=0 --bar=1 --bar=2 will not fail with error: The argument '--foo' was provided more than once, but cannot be used multiple times (or the same for --bar), and both foo, and bar with value 2 would be yield (resulting in the same as calling with only --foo --bar=2).

Or even better, maybe a .setting(AppSettings::POSIX) defined once would enable the previous behavior. Why would defining the same option twice or more yield an error? I just played with some command line tools here (git status --short --short --short, ls -l -l -l, vi -R -R -R README.md) and none complains of options provided multiple times...

[kbknapp]

Thanks! I like the AppSettings idea too as defining all args as overridable by themselves would be handy.

[ericbn]

Cool. Actually the POSIX specifications don't state nothing about overriding arguments. But the way the POSIX implementation usually involves a loop through the arguments, same arguments just get a count increment or override the previous assigned one.

Maybe the AppSettings could be something more explicit than just AppSettings::POSIX...

[lilyball]

There definitely should be an AppSetting for this (POSIX isn't a good name for this, maybe AppSetting::AllowDuplicateFlags?). And I suppose a per-arg setting as well, in case you want to e.g. allow it in general but disallow it on certain flags that take arguments (for example, you'd probably want to allow it on flags that take arguments specifying config values, e.g. sort options, but disallow it on flags that take arguments specifying input files).

exa just ran into this issue with its argument parsing (which was getopts), and it looks like their solution is to implement a custom argument parser.

And it looks like ripgrep also hit this limitation.

[kbknapp]

This tweet got me thinking about this issue some more, and I'm thinking that because of the new lazy validation I'm doing this could actually be an easy add, and easily forward portable to the v3-master branch. I'm going to take a look at this tomorrow see and if it's as easy as I think it'll be.