Could not downcast to type alias

[2moe]

Please complete the following tasks

• I have searched the discussions
• I have searched the open and rejected issues

Rust Version

rustc 1.68.0-nightly (61a415be5 2023-01-12)

Clap Version

4.0.32

Minimal reproducible code

use clap::Parser;
type OptVal = Option<String>;

#[derive(Parser, Debug)]
struct Cli {
    #[arg(long, value_parser = ["turbo", "auto", "slow"])]
    mode: OptVal,
}

fn main() {
    let args = Cli::parse();
    dbg!(&args.mode);
}

Steps to reproduce the bug with the above code

cargo r -- --mode auto

Actual Behaviour

thread 'main' panicked at 'Mismatch between definition and access of `mode`. Could not downcast to core::option::Option<alloc::string::String>, need to downcast to alloc::string::String
', src/main.rs:117:11
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected Behaviour

[src/main.rs:21] &args.mode = Some(
    "auto",
)

Additional Context

If I don't use OptVal type, and use Option<String>, I won't have this problem.

Debug Output

[dependencies]
clap = { version = "4.0.32", features = ["derive", "wrap_help", "unicode"] }

[epage]

That application is defined to require a subcommand, so if one isn't specified you get that error.

To make something optional (arg, subcommand), you need to wrap it in an Option. One way to think of it is there isn't a way to construct Cli right now as what will we put in the run field when no subcommand is specified.

[2moe]

@epage Thanks.
I have amended this issue and I am not sure if this is appropriate.
For type OptVal = Option<String>, clap will not resolve this type alias(OptVal), but will resolve Option<String>.
Is this an intentional approach?

[epage]

Clap does a textual comparison on the type to determine what behavior is assumed so people can override it, so type aliases are intentionally treated as unique types. #4626 is discussing changing / improving the situation.

[epage]

As this is expected behavior, I'm closing this out.