Optional and mandatory options

[da2r-20]

I think it would be nice to have optional and mandatory options
that way no validation is needed to be done by the user

[jarro2783]

As I've said in several previous issues #44 #25, I don't think that this sort of logic belongs in this library. The main reasoning is that usually options are not just mandatory or optional., but something more complicated. Take for example tar, it has a mutually exclusive set of options, and a bunch of options that only go with other options.

tar: You must specify one of the '-Acdtrux', '--delete' or '--test-label' options

That said, since this has been requested a few times, I think a separate validation library would be appreciated by a few people. I will work on this at some point, but I can't guarantee getting to it straight away.

[da2r-20]

Thanks!
Some how I missed #44 when searching the issues.

I agree a validation should be on different defined combinations of the arguments
In-order to decide if a set of arguments is valid or not.

I'll be happy to contribute, let me know.

[dakka]

I think a separate validation library is not necessary. If each option could optionally specify required and/or excluded arguments, resolving conflicts is then left to the user to define and the validation simply enforces the supplied rules.

[vladimirgamalyan]

For simple cases it would be very useful to have required options (like boost::program_options::value<>()->required()). At least it allows to drop annoying checks for an every required option.
Of course, for more complicated cases, users can figure out it with own logic.

[slidertom]

I think this is critical issue it breaks open/close principle.
e.g.:
script calls:
app.exe -p "test1"
after some time I've updated application with the additional parameter
and now script calls:"
app.exe -p "test1" -x "test2"
-> previous version of the app.exe can not be used with the extended command line
how to fix this problem? Library does not allow any extensions -> and forces to update all
external environment my case:
somehow try to retrieve app.exe_version
if ( app.exe_version == 1 )
app.exe -p "test1"
else if ( app.exe_version == 2 )
app.exe -p "test1" -x "test2"

[jarro2783]

I think this is critical issue it breaks open/close principle.
e.g.:
script calls:
app.exe -p "test1"
after some time I've updated application with the additional parameter
and now script calls:"
app.exe -p "test1" -x "test2"
-> previous version of the app.exe can not be used with the extended command line
how to fix this problem?

I don't understand the problem. I don't see how this is related to whether the library throws an exception when a mandatory option is missing.

Are you talking about allowing unrecognised options without raising an error?

[slidertom]

>Are you talking about allowing unrecognised options without raising an error?
I do expect, that mine old app.exe will work even some options are unrecognized.
Yes, error should not be raised, but command line also must be parsed.
-> should I be forced to update all the old app.exe binary versions in
case of any command line extension for the new versions?
I do not think so.
Or maybe command line versioning must be tracked by the script developer?
I do not think so.

[jarro2783]

That's a separate discussion then which I will move to another issue.

Although it is easy to do, the main problem with unrecognised options is how to recognise their arguments. For example is --foo bar an unrecognised option --foo with argument bar, or is it a boolean that takes no argument followed by a positional argument?

[jpmvferreira]

For simple cases it would be very useful to have required options (like boost::program_options::value<>()->required()). At least it allows to drop annoying checks for an every required option.
Of course, for more complicated cases, users can figure out it with own logic.

I'm not sure if this is still open to discussion or not, because this is quite an old issue, however the only thing that would make this library be perfect to me is the required arguments and if the required arguments were not given it would simply print the --help message.

Considering that this can be an optional parameter it wouldn't force users to use this but instead would allow small more linear programs to keep it's code simpler and avoid checking things manually.

[jarro2783]

I still have some plans to address this. I wanted to make a separate validator that you can run against the parsed options.

[carlosgalvezp]

Hi! What's the status on this issue?

[liwei46]

I am expecting this feature.