If option argument parsing (or end of args testing) is permitted to fail without throwing an exception, we could support optional arguments and options that take different sorts of arguments with e.g.
optional<int> v;
to::opts options[] = {
{ v, "-f", to::lax },
{ to::set(v, 1}, "-f" }
};
trying to parse an integer argument to an option -f to assign to v and then, if it fails to parse an integer, instead just sets v to 1.
Caveats:
- String arguments are going to be greedy, and would gobble e.g.
-- as an argument even if to::lax is given, based on the approach above.
- The order of options presented to
to::run is crucial for this to operate as expected.
If option argument parsing (or end of args testing) is permitted to fail without throwing an exception, we could support optional arguments and options that take different sorts of arguments with e.g.
trying to parse an integer argument to an option
-fto assign tovand then, if it fails to parse an integer, instead just setsvto 1.Caveats:
--as an argument even ifto::laxis given, based on the approach above.to::runis crucial for this to operate as expected.