Non-absolute positional argument support

[kit-ty-kate]

Currently cmdliner only supports absolute positional arguments (e.g. the indexes will not shift if an optional positional argument is missing), which makes it difficult to support things like ARG1 [ARG2] ARG3:

$ ./a.out a b c
arg1 = a
arg2 = Some b
arg3 = c
$ ./a.out a c
test: a required argument is missing
Usage: test [OPTION]… ARG1 [ARG2] ARG3
Try 'test --help' for more information.

(taken from ocaml/opam#6124 (comment))

I'm not sure how that translates to the internals of cmdliner but my proposal would be to automatically shift positional arguments depending on the current number of unnamed arguments with regard to the definition.

For example in the above case, arg3 would shift to be as if it was defined as pos 1 if the number of positional arguments is 2.

This can be extended to more complex cases such as: ARG1 [ARG2] ARG3 [ARG4] ARG5 if we say that cmdliner will try to fit all required arguments first and then fill the optional ones starting from the left. With that example that would be:

• Calling the command with less than 3 arguments would be an error (as expected)
• Calling the command with 3 arguments would fit ARG1, ARG3 and ARG5
• Calling the command with 4 arguments would fit ARG1, ARG2, ARG3 and ARG5
• Calling the command with 5 arguments would fit ARG1, ARG2, ARG3, ARG4 and ARG5

I don't personally need that feature so feel free to discard it as it seems to add complexity, but if it's ever useful to anyone else maybe it's worth considering.

[dbuenzli]

I'll have a look but I suspect it's complex to implement (context-aware) and not worth it.

These things are easier to simply resolve via a dedicated term in which you a function to perform the logic yourself using both the full power of OCaml and Cmdliner's error reporting capabilities.

[dbuenzli]

This can be extended to more complex cases such as: ARG1 [ARG2] ARG3 [ARG4] ARG5

No but this won't work you immediately get into ambiguities if the arguments have undistinguishable grammars. There are already enough amibiguities in cli parsing, let's not add more.

Closing as bad idea®.

[mbarbin]

@dbuenzli do you have any thoughts regarding maintaining the status quo of accepting such specs vs introducing a new explicit error during the cli validation step?

The rejection would be motivated to prevent scenario like the one given in the PR description:

$ ./a.out a c
test: a required argument is missing
Usage: test [OPTION]… ARG1 [ARG2] ARG3
Try 'test --help' for more information.

[dbuenzli]

I think if we can reject them it's good. The docs already mentions that you should not try to extract a positional argument with more than one combinator I think someone tried at some point but I can't find the PR.