default_value may not be included in possible_values and only checked in a runtime

[Gordon01]

Please complete the following tasks

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

Clap Version

3.0.0-rc.7

Describe your use case

A configuration when a default_value is not listed in possible_values is valid and i only get error in runtime.

example
#[clap(short, long, default_value_t = 64, possible_values = ["16", "32"])]
this also works:
#[clap(short, long, default_value = "64", possible_values = ["16", "32"])]

Describe the solution you'd like

I want to get error at compile time.
Maybe implementing a #3201 may automatically resolve this issue.

#[clap(short, long, default_value_t = 128, possible_values = ["12", "16", "32"])]
fat: u8,

error: default value is not in range of possible values

Alternatives, if applicable

No response

Additional Context

No response

[epage]

It would help if you included a fully working code sample and the current runtime error output. I have some guesses as to which errors you are seeing but I'd have to recreate a working sample to verify. This is needed to triage this for how important it is for resolving.

[Gordon01]

use clap::Parser;

#[derive(Parser)]
#[clap(author, version, about)]
struct Cli {
    #[clap(default_value = "4", possible_values = ["1", "3", "5"])]
    count: u8,
}

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

    println!("Count: {}", cli.count);
}

cargo run -q

error: "4" isn't a valid value for '<COUNT>'
[possible values: 1, 3, 5]

So yeah, this is just an ergonomic issue, but it would be great if this error could be checked at compile time.

[epage]

Thanks! i'm surprised we leave this to being an error from the validators.

The first priority would be to add a debug assert for this. That will catch it in all of our APIs. In our migration guide, we've recommended making tests out of the debug asserts. We should also add that to the regular documentation.

#2740 proposed porting our debug asserts to run at compile time. Not all of them thoroughly can (#3133) so even if we ignored the builder API, we'd still need the debug asserts in some cases. This is one that wouldn't run into that problem. When considering the builder API, we also have to deal with code duplication and code drift. That makes it unlikely for us to duplicate the debug asserts at compile time.

If we haven't, we should probably also have a debug assert that validates the default value against the validator function, if present.

[epage]

Because of #4643, #5017 reverted the fix for this