required conflicts with required_unless*

[Ciubix8513]

Please complete the following tasks

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

Rust Version

1.67.1

Clap Version

4.1.6

Minimal reproducible code

use clap::{Parser};

#[derive(Parser,Debug)]
struct Args{
    #[arg(short)]
    a: bool,
    #[arg(required_unless_present("a"))]
    test: String, 
}

fn main() {
    let args = Args::parse();
}

Steps to reproduce the bug with the above code

cargo run

Actual Behaviour

'main' panicked at 'Argument test: required conflicts with required_unless*', /home/luna/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-4.1.6/src/builder/debug_asserts.rs:186:13

Expected Behaviour

required_unless* should automatically infer remove required and the code example should run normally

Additional Context

Currently to fix this issue you need to add default_value to the arg definition, and then it works as expected

Debug Output

No response

[epage]

Even if we resolved things to prevent that assert, it would then fail at runtime. If the "unless" case happens, clap will have nothing to put into that field and will report an error.

You either need to make the argument optional by changing the type from String to Option<String> or provide a default.

[Ciubix8513]

Yea, that makes sense.
But wouldn't it be possible that the compiler gives an error saying that required_unless* requires the argument to be Option<> or have a defualt value?
I'm not quite sure if that's possible (I'm pretty new to rust), but that would make it less confusing, to people who are not as familiar with Clap or Rust.

[epage]

Yes, ideally, more of our checks would be done at compile-time. A couple of challenges with that

• We support merging structs and the compiler doesn't tell us anything about the other struct
• There are a lot of corner cases for how these arguments interact that it would be complex and brittle, especially because...
• This would be hard to maintain as we'd have to have a copy of all of the rules available at both compile time and runtime.

See also #3133

[epage]

As it seems this direct issue is resolved, I'm going to go ahead and close thos