Requiring one Option or another, not both

[gbitzes]

Hi, is there some way to require that one of { "--option1", "--option2" } is present, but not necessarily both? I looked at the documentation and examples, and couldn't figure out if this is possible. Do I need a custom callback?

By the way, excellent work on this library! Something like this was sorely needed in C++.

[henryiii]

Not really, the current way to do that would be to use a set, but that's a different syntax. What would a good api for that be? Maybe passing other options to the ->required() method?

[gbitzes]

I was thinking of either having a variadic require_one method in App:

auto opt1 = app->add_option( ... );
auto opt2 = app->add_option( ... );

app->require_one(opt1, opt2, opt3);
// could also be app->require_at_least(2, opt1, opt2, opt3, opt4);

Or the ability to make a Group required, such as app->require_group("Some group");

The first seems more flexible (allows more complicated networks of requirements, and overlapping sets), but the second easily allows expressing this in the auto-generated help string for groups.

But then again, we could auto-detect if a group has an "at least N" requirement.. I'm leaning towards the first approach.

I'm not really sure.. not a big fan of a variadic ->required() though, the intent doesn't seem clear when reading the code, IMHO.

Python's argparse takes the second approach.

[OlivierHartmann]

Hi,
I am not completely sure this is the same issue but quite an identical need so I comment this flow.

Here is the simple example:

#include <CLI/CLI.hpp>

int main(int argc, char **argv) {

	CLI::App app{"App to demonstrate a paradox."};

	std::vector<int> range;
	auto range_option = app.add_option("--range,-R", range, "A range")->required();

	int min, max, step = 1;
	app.add_option("--min,-m", min, "The minimum")->required()->excludes(range_option);
	app.add_option("--max,-M", max, "The maximum")->required()->excludes(range_option);
	app.add_option("--step,-s", step,  "The step", true)->excludes(range_option);

	CLI11_PARSE(app, argc, argv);
}

With "--range 1 2 3" argument, I get: "--min is required".
With "--min 2 --max 3 --step 1" arguments, I get: "--range: At least 1 required"
With "--min 2 --max 3 --step 1 --range 1 2 3" arguments, I get: "--range excludes --min"

A solution would be to remove the "required" flag but then the user may give nonsense. Is there a solution ?

Thank you.

[AlexanderAmelkin]

@henryiii, you marked this issue as closed and resolved in 1.5, but it looks like only the "not both" part is actually resolved. At least I was unable to find a way to "Require one option or another". I mean, as @OlivierHartmann shows above, you can require one AND another option to be required, but that doesn't work if they are mutually exclusive. How do you specify OR ? An example would come in handy. There is currently no example for excludes().

[henryiii]

This issue is still open, only part of it was resolved in 1.5, which is why it was mentioned in 1.5 but only the 1.5 release issue was closed.

I think the proper way to do this might be by expanding groups to be a full object, then allowing a group of options to just require 1 (or x) to pass. It's not in the immediate plans but a PR would be welcome, at least if well done. require_at_least is possible instead, but I'm not sure how that would internally be represented, groups might be easier/better/more transparent in the help.

[phlptp]

One possibility would be adding require_option functions just like require_subcommand functions to App class. Then if you wanted only one of a subset of options you could define those options in a "nameless" subcommand and specify the require_option as desired. I think the nameless subcommands could function as a group object like you mentioned already.

The app would count the number of options that had results after parsing just like it does for subcommands.

[henryiii]

That might work, actually. So the idea is just to require N options for an app (say, 1), and then nameless subcommands allow you to build groups. Not sure how it would look in the help, but it would be a simple addition.

[phlptp]

You would probably want a min and max just like for require_subcommand but it should be reasonably straightforward to implement.

[AlexanderAmelkin]

This "nameless subcommand" approach sounds to me like an ugly kludge. I would prefer the existing groups to become full-scale objects with properties. However, there definitely are cases where mutually exclusive option groups can exist within a logical options group. Then binding mutual-exclusiveness to a group wouldn't work unless groups would be able to have child groups.