Implicit values break value assignment without equals sign

[blackworm27]

I am trying to allow the following kind of command line uses:

1. <option not specified> yields default value (e.g., {""})
2. --option with no argument yields implicit value (e.g., {"all"})
3. --option a yields {"a"}
4. --option a --option b yields {"a", "b"}

Instead, #3 yields {"all"} and #4 yields {"all", "all"}. It seems using implicit_value forces the user to use the --option=a,b syntax. Is this intended?

Here is my code fragment. I am using v3.2.1.

    _currentOptions->add_options()(
        "option",
        "description",
        cxxopts::value<std::vector<std::string>>()->default_value("")->implicit_value("all"));

Thank you for any guidance.

[jarro2783]

This is a problem that often comes up, and I don't know if there are any better ways to solve this. The problem with implicit options is that the parser can't tell if the next option is supposed to be attached to the implicit option or is a standalone argument (positional argument). So it basically forces you to use =. In your example 4, it's the same as writing

--option --option a b

which gives you (all, all) for --option, and two positional arguments a and b.

[blackworm27]

Thanks for your reply. I don't tend to use positional arguments. Perhaps a solution would be a mode where any positional arguments must follow a specific switch (typically --). In that mode, any arguments not beginning with - are parsed as appending to the vector associated to the previous switch. The preceding switch would have to be a vector or there would be a parse error.

Anyway, I understand this is a minor limitation and a new mode may not be feasible or desired. Thanks for your response and for sharing this useful tool!

[dmt4]

Isn't what one would expect from --option a be for a to be an argument to --option if --option is able to take arguments, rather than a being a positional?

In other words, to resolve the ambiguity there must be some priority.

The --option -a situation seems simpler: if -a is a known option then --option gets its implicit value, otherwise it gets -a.

I can submit a small MR if it will be useful.

[blackworm27]

@dmt4 Personally I would prefer to disallow option arguments starting with - (like your -a), forcing the use of the --option=-a syntax if the user needs that. I think something like --option -a without -a as a valid option is more likely to be a user error than something intended. Your suggestion would also mean the semantics of existing scripts change if (say) the -a option were added later.

As a reminder, I'm suggesting a new, optional mode or parsing flag, where positional arguments would only begin to be counted after -- (and anything after -- would be a positional argument).

[dmt4]

I have a what looks to me a valid use, although I see how it can be a source of error, in one application of mine I have "-a,--axis" option which must take one of x,-x,y,-y,...some expression of these and is a bit less hassle to type -a -x than -a=-x (-x -y etc.. do not exist as options in this code) but that's secondary matter.

The more inconvenient thing is when an option with implicit value requires = no matter what comes after while option without implicit value is happy with a space or =.

Totally agree about the mode where everything after -- is positional, it is a classic behaviour and a good idea to support in my view.

[jarro2783]

Adding a -- mode seems reasonable, although I'm not sure if it should change the behaviour of parsing before the --.
The other tricky thing about implicit options is that flags that are switches are treated as a boolean with an implicit true, so changing whether the next argument is parsed as part of the implicit would break every boolean option.

[dmt4]

The set of possible values for booleans is fairly restricted so they can safely ignore anything else.