arg_required_else_help() doesn't trigger when passing options

[djc]

I'm in the process of upgrading rustup from clap 3 to clap 4. The (hopefully) final remaining issue is what happens when we run rustup -v. With our setup in clap 3 (using SubcommandRequiredElseHelp), calling rustup and rustup -v would have the same result, of showing the help. With clap 4 (using subcommand_required(true).arg_required_else_help(true)), the same behavior happens for rustup but rustup -v instead shows an error instead of the help:

error: error: 'rustup' requires a subcommand but one was not provided
  [subcommands: dump-testament, show, install, uninstall, update, upgrade, up, check, default, toolchain, target, component, override, run, which, doc, docs, man, self, set, completions, help]

This seems like it might be a bug? Arguably arg_required_else_help() should trigger help if there is no subcommand, even if some options are present, right?

[epage]

arg_required_else_help is saying any arg, whether it be a positional, a flag, or a subcommand, is required, else help will be shown.

The removal of SubcommandRequiredElseHelp was intentional and not just to shrink clap's API surface / code size. If no arguments are provided, then it can make sense to show the help. However, when the user starts passing in arguments, thats showing an intention and we should report what went wrong with that intention which is much better served with subcommand_required(true).arg_required_else_help(true)),

[epage]

To be clear, in both cases, its an "error" and a bad exit code is reported, so its just the output that has changed for any binary transitioning between these APIs.

[djc]

Okay, conceptually in my mind a "flag" isn't an "arg", although I somewhat understand this is how the clap glossary.

So is there some way to override this behavior?

[epage]

Naming is hard. This is more referring to an arg, like argv as in before being interpreted, rather than arg like a positional argument.

To be more clear, there is not a way to override this behavior though you could sort-of implement it manually if you don't make the subcommand required and show the help your self. More of my point was that changing this shouldn't be breaking from rustup's perspective and, in my mind, there is little reason to keep the old behavior and unless there is a specific reason to do so which has not been given and I cannot think of one for rustup.

[djc]

Having thought about this some more, this still feels to me like a regression or missing feature. Conceptually, the concept of arg_required doesn't make sense to me because it doesn't really make sense for a "flag" to function like this, because flags by definition should be optional -- unless they are (sub)command-like options. In that sense, conflating all of positionals, flags and subcommands in the same thing is just confusing and leads to issues like this.

To be more specific, passing -v for --verbose only (as an example of what I would call a "flag") to me clearly doesn't show an intention -- it just specifies that the given output should be more elaborate.

[epage]

To be more specific, passing -v for --verbose only (as an example of what I would call a "flag") to me clearly doesn't show an intention -- it just specifies that the given output should be more elaborate.

Except clap doesn't know about that flag and no flag will affect the result of arg_required_else_help.

In that sense, conflating all of positionals, flags and subcommands in the same thing is just confusing and leads to issues like this.

To me, this feels like over-thinking it. The intent is if you just run the binary by itself, it will show help. If you do anything else, it will be processed like normal.