Derive should only show help when argc==1 rather than missing subcommand

[epage]

Please complete the following tasks

• I have searched the discussions
• I have searched the existing issues

Rust Version

rustc 1.57.0 (f1edd0429 2021-11-29)

Clap Version

v3.0.6

Minimal reproducible code

use clap::{AppSettings, Parser, Subcommand};

#[derive(Parser)]
#[clap(author, version, about, long_about = None)]
#[clap(global_setting(AppSettings::PropagateVersion))]
#[clap(global_setting(AppSettings::UseLongFormatForHelpSubcommand))]
struct Cli {
    #[clap(short, long, parse(from_occurrences), global = true)]
    verbose: usize,

    #[clap(subcommand)]
    command: Commands,
}

#[derive(Subcommand)]
enum Commands {
    /// Adds files to myapp
    Add { name: Option<String> },
}

fn main() {
    let cli = Cli::parse();

    // You can check for the existence of subcommands, and if found use their
    // matches just as you would the top level app
    match &cli.command {
        Commands::Add { name } => {
            println!("'myapp add' was used, name is: {:?}", name)
        }
    }
}

Steps to reproduce the bug with the above code

$ cargo run -- -v

Actual Behaviour

$ cargo run -- -v
   Compiling test-clap v0.1.0 (/home/epage/src/personal/test-clap)
    Finished dev [unoptimized + debuginfo] target(s) in 0.70s
     Running `target/debug/test-clap -v`
test-clap 0.1.0
Me
From Cargo.toml

USAGE:
    test-clap [OPTIONS] <SUBCOMMAND>

OPTIONS:
    -h, --help       Print help information
    -v, --verbose    
    -V, --version    Print version information

SUBCOMMANDS:
    add     Adds files to myapp
    help    Print this message or the help of the given subcommand(s)

Expected Behaviour

$ cargo run -- -v
   Compiling test-clap v0.1.0 (/home/epage/src/personal/test-clap)
    Finished dev [unoptimized + debuginfo] target(s) in 0.67s
     Running `target/debug/test-clap -v`
error: 'test-clap' requires a subcommand, but one was not provided

USAGE:
    test-clap [OPTIONS] <SUBCOMMAND>

For more information try --help

Additional Context

To reproduce the desired behavior:

#[clap(setting(AppSettings::SubcommandRequired))]
#[clap(setting(AppSettings::ArgRequiredElseHelp))]
#[clap(unset_setting(AppSettings::SubcommandRequiredElseHelp))]

This was inspired by a conversation in #2513

In my mind, showing of help should be reserved for when the user has taken no action but SubcommandRequired allows the user to pass some arguments. In those cases, we should be showing a more specific error message than a long, generic message that takes the user some work to figure out what the next steps are.

Debug Output

No response

[epage]

I do not think this dramatically breaks user expectations that this would be considered a breaking change and can happen anytime,

[epage]

Personally, I think we should deprecate and remove SubcommandRequiredElseHelp in favor of SubcommandRequired | ArgRequiredElseHelp (resolving this issue doesn't need to be blocked on a decision about this but we will then need to create a separate issue). The behavior seems too close to justify having both. We are working to find ways to simplify clap to reduce API overhead (didn't know you could get this better behavior and actually thought this was what I was getting) and code bloat from too much built-in customization.

29ca7b2 and #133 don't include details as to why we have both.

[epage]

I guess a question for 4.0 is if we should stop including ArgRequiredElseHelp by default and require users to opt-in. I'm mixed on that.

[epage]

Experimented with this recently. SubcommandRequired has higher precedence than ArgRequiredElseHelp. We'd need to swap these.