akamensky / argparse

Argparse for golang. Just because `flag` sucks
MIT License
604 stars 62 forks source link

Add support for nargs functionality #22

Open akamensky opened 6 years ago

akamensky commented 6 years ago
  1. Take constant or variable number of arguments that follow
  2. Important for optional arguments
  3. Does not make much sense for positional arguments
goofinator commented 4 years ago

What is your vision of narg functionality? I think it's should be an additional functions for basic types, like: IntNarg, FloatNarg and so on.

narg should be the integer value. if narg>0 - it strictly sets count of expected parameters. narg<=0 (or <0 - look below) sets default behavior, which is to accept all parameters till next optional argument or till line end. In cooperation with Options.Required it covers all functionality of "*", "?", "+" of python library.

Here are some disturbing moments.

  1. narg 0 (default value). Should it be interpreted as "get all parameters till the line end or next argument?" or like 1? First case is acceptable for optional arguments, but in case of positional arguments it would be acceptable only for the positional argument at the end of arguments list.
  2. When positional arguments will be realized, what would be the desired behavior in case of narg <0 followed by positional argument? Should this situation be forbidden or last parameter(or parameters, if positional argument is a narg too) just will be moved to fill positional argument?