Throw error if subcommand is missing

[Constantine Molchanov]

When an argument is missing, an error is thrown. So this code guarantees that the param is provided:

commandline:
  argument foo, int

But with subcommands, this is not so. This code does not guarantee that the command is specified:

commandline:
  subcommand sub, "sub":
    argument foo, int

[Guillaume Viger]

Thanks for the comments!

Right now this is working as it is 'supposed' to: we want to allow the flexibility of defining subcommands AND behaviour if there are none. I would extend the example above with the following:

commandline:
  subcommand sub, "sub":
    argument foo, int

if sub:
  echo "Provided a subcommand"
else:
  echo "Didn't provide a subcommand"

This allows you the developer to decide what happens in the case where there are no provided subcommands.

It also allows you to mix and match subcommands and top-level arguments:

commandline:
  subcommand sub, "sub":
    argument foo, int
  argument iAmRequired, string

Either the CLI starts with "sub" and provides an int followed by a string or it can start with a string different from "sub" and the fact that the subcommand was not used is kept in the variable sub.

Does that capture the kind of scenario(s) you had in mind?

[Constantine Molchanov]

Hi! Thanks for the quick and friendly response!

Putting an else clause is exactly how I do it right now. It does do the trick. I just thought there might have been a better way.

Adding a top-level argument also works, but it looks like an ugly workaround if you don't actually need the argument.

Since you're the product owner, and you believe it's how it should work, I don't see a problem in closing this issue as "no fix."