Allow many positional arguments

[Jackojc]

It would be nice to be able to have a feature whereby you could gather many positional arguments at the end of a command for something like a compiler.

For example, imagine a use case like this:

compiler file1 file2 file3

Currently I don't believe it is possible to do this.

I imagine using it would look something like:

std::vector<std::string> = program.get_trailing();

which would just return all positional arguments at the end regardless of how many.

[zhihaoy]

Often cmdline parser updates or returns updated (argc, argv) pair so that other 3rd-party parsers can continue to work on the rest of the arguments.

argparse seems to be working on its own storage, in that case a pair of updated (begin, end) iterators would be similar. For example,

auto [first, last] = program.parse_args(argc, argv);
auto tailing = std::vector(first, last);  // you got the unused arguments

[Jackojc]

I like that idea, very clean.

[zhihaoy]

Hmm, this is more complicated than I thought.

Must extra arguments be consecutive?

Given the trailing model, let's say

program.add_argument("-I");
program.add_argument("output");

Does this work?

./test pos1 pos2 -I opt1 pos3

If both pos2 and pos1 are deemed unused, then unused arguments must be regathered, so iterator doesn't work (unless we invent our own iterator to do parsing, which would be fancy).

Extra positional arguments are illegal given existing semantics

If the above is deemed illegal, whether anything with unused arguments are legal is still debatable.

./test pos1 -I opt1 pos2 pos3

Given the existing parse_args, the above throws exception. In order to not to introduce a runtime breaking change, we may have to make the behavior configurable. For example, by introducing a continuation:

parse_args(argc, argv, argparse::throw_if_exceeds_maximum_positional_arguments);
// ^^ this is the default, no need to pass the 3rd argument
auto some_return_value = parse_args(argc, argv, argparse::return_trailing_positional_arguments);

Lifetime

parse_args(argc, argv) cannot return iterators that point to std::vector because that's a local variable. At best it can return two pointors into argv, but that's less convenient. parse_args({"test", "-L"}) cannot return iterators at all because that's a temporary. Creating an lvalue overload in additional an rvalue overload can workaround this issue but nobody will actually use the lvalue overload.

Thoughts so far

1. we need configurable semantics that users can choose
2. if non-consecutive positional arguments are allowed, we will need storage in, for example, ArgumentParser
3. if we have storage, lifetime isn't an issue
4. but if we have storage for these arguments, will users want actions on them? Help messages? That lean towards capturing the extra positional arguments' semantics in Argument...

[zhihaoy]

I studied Python's argparse, and was convinced that there are two demands.

The first one is to have a kind of Argument that expects "remaining" number of arguments. The argument itself maybe positional or optional. It consume everything, regardless positional or optional, until the end.

The second one is to parse known arguments, and leave the rest to other libraries. The rest of the arguments are not associated with argparse::Argument and actions don't work on them.

The demand raised in this issue is the former, and I drafted #57 for it. The second demand is worth to investigate separately.