Inverse of requires_if (i.e. requires_if_not / required_unless_eq_any)

[rob-p]

Hi,

I have a setup where I would like to require some argument (say -b <val>) to be required only if some other argument (say -a has a value other than foo). For example, the user should be able to execute the program as:

prog -a foo

but not

prog -a bar

In the second case, it should be required that -b is passed, so that e.g.

prog -a bar -b baz

would be OK. There are a small fixed number of values which, if provided to -a should obviate the need for -b. We have the opposite of this with requires_if, but I don't know of a way to negate that condition. Is there somewhat to achieve functionality equivalent to requires_if_not? Thanks! cc @DongzeHE.

P.S. Given the naming conventions that currently exist, I think a better name for what I'm suggesting here would be required_unless_eq_any. It would be a natural counterpart of required_unless_present_any.

P.P.S. I have tried to use default_value_ifs, but it doesn't seem to be working. Here is a MWE of what I have:

#[command(group(
    ArgGroup::new("filter")
    .required(true)
    .args(["knee", "unfiltered_pl"])))]
Quant {
/// chemistry
#[arg(short, long)]
chemistry: String,

/// use knee filtering method
#[arg(short, long)]
knee: bool,

/// use unfiltered permit list
#[arg(short, long, 
    default_value_ifs([
        ("chemistry", ArgPredicate::Equals(OsStr::from("10xv3")), Some("*")),
        ("chemistry", ArgPredicate::Equals(OsStr::from("10xv3")), Some("*")),
    ])
 )]
unfiltered_pl: Option<PathBuf>
}

So what I intend here (but may be conveying incorrectly) is that if --chemistry 10xv3 or --chemistry 10xv2 is passed, then the user should not have to explicitly provide the --knee or --unfiltered_pl arguments because we will populate --unfiltered_pl with a default value of *.

[epage]

Sorry for the slow response!

Another route for this is to extend ArgPredicate.

A challenge we have is there is an arbitrary set of functionality people ask of clap while we are working on shrinking clap (#2037, #1365) and we have been exploring other ways of handling this in #3476. This makes me hesitant every time there is a new request for an additional variant of existing functionality.

[epage]

Note: #4682 was opened for this