ArgMathces::args_present behaviour with ArgAction::SetTrue

[Vaider7]

Please complete the following tasks

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

Rust Version

rustc 1.85.0-nightly

Clap Version

4.5.23

Minimal reproducible code

fn main() {
    let cli = Command::new("myapp").arg(
        Arg::new("show")
            .short('s')
            .long("show")
            .action(ArgAction::SetTrue),
    );
    let matches = cli.get_matches_from(["myapp"]);
    assert!(!matches.args_present());
}

This code panic with message

assertion failed: !matches.args_present()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

No args were provided, but args_present() returns true, which I think counterintuitive

Steps to reproduce the bug with the above code

cargo run

Actual Behaviour

matches.args_present() returns true

Expected Behaviour

matches.args_present() returns false if no arguments were provided despite Arg::new("show").action(ArgAction::SetTrue)

Additional Context

No response

Debug Output

No response

[epage]

The documentation says "present on command line" but the behavior is if any ids are present, like contains_id
https://github.com/clap-rs/clap/blob/master/clap_builder%2Fsrc%2Fparser%2Fmatches%2Farg_matches.rs#L578

With SetTrue, false is a default which makes it so it contains the id.

The value_source is the defínitive way to know.

The question is whether we should change the docs or the behavior.

[Vaider7]

Well, personally, I think it's very important to be able to check whether some args were provided via command line or not. If we change the docs, the behavior of args_present remains the same. And if so, args_present is not useful for any CLI setup, which uses action(ArgAction::SetTrue), because it will always return true regardless of whether args were provided or not. So my personal suggestion is that args_present should return presence of arguments despite any Command setup.

I'm not very familiar with clap yet, so I'm sorry if I'm saying nonsense things

[epage]

In #3382, we added args_present() as a mirror to is_present(id).

In clap 3, flag's only set a value when passed in. With #3786, the new SetTrue and SetFalse actions started setting defaults. In these cases, we could no longer conflate "present in the structure" with "present on the command line".

In #3814, we renamed is_present(id) to contains_id(id) to better fit with the new actions.

We also have the IsPresent predicate which does check the ValueSource.

[Vaider7]

I see, thank you for the explanation.

But I still deeply convinced that checking if "any arg presented on the command line" is important feature (at least for my purposes). IsPresent can be used for only one concrete arg, and if there was similar functionality for ArgMathces, that would be great and very useful

[epage]

Note that wasn't necessarily a comment about what should be done for this issue but notes I took as I researched how we got here and how the term "present" is used. This is important background for understanding where to go from here.

For instance

• The original intent was to communicate if arguments are present on the command-line which we are no longer upholding
• The term "present" in the name matches that original intent
• We've been in this situation for 2.5 years and no one has noticed until now

[Vaider7]

I think for my initial purpose to check whether any argument was provided on the command line or not the next code can be used:

// no args provided
if std::env::args() == 1 {
    // do some stuff ...
}

But the current doc of args_presnt() states:

• Check if any args were present on the command line

And I find it confusing, because it's not true it we use Arg::new("somearg").action(ArgAction::SetTrue)

So my suggestion is just change its documentation. For checking presence of arguments on the command line the above simple code can be used

[epage]

I think for my initial purpose to check whether any argument was provided on the command line or not the next code can be used:

// no args provided
if std::env::args() == 1 {
// do some stuff ...
}

...

So my suggestion is just change its documentation. For checking presence of arguments on the command line the above simple code can be used

That works for the root command but not any subcommands.

If we changed the documentation, we'd need to also deprecate and make a new name available because present has a specific meaning in clap.

[epage]

Doing a quick browse on github

• kou: intended as documented with flags, subject to this issue
• simple-ftp-client: intended as documented with flags, subject to this issue
• erdtree: intended as documented with flags, subject to this issue (out of date fork)
• solana-did-method: unsure
• Chads-Advent-of-Code: unsure
• zk-avail-da/da-sender: unsure
• kmerutils: assumes subcommands are checked (shouldn't this be broken?
• my_rust: intended as documented and with what is intended to be a flag but a bug is in the code otherwise they'd run into this issue
• Rust-CLI/unique: intention is unclear
• kaivm: intended as documented but no flags used
• beancount-language: intended as documented, with a flag, but in a way that this issue doesn't change behavior
• BlinkSync: intended as documented, I think? but the shirt-circuit is dead because of required arguments
• lotr: intended as documented with no flags
• MovieChaptersPLS: intent unclear, used with flags and will panic if false but some arguments are required making it so the panic shouldn't be hit
• bat: on cache subcommand, intended as documented but its dead code because some arguments are required
• rosu-tracker: intended as documented but no flags
• nisq: intended as documented, no flags
• cim: intended as documented, no flags
• mdbook-embeddify: unclear intent, maybe thinking it includes subcommands, like args_required_else_help?
• cxl-fabric-amanger: dead code
• qpass: intended as documented, I think? No flags
• kvs: intended as documented, no flags
• RustLeetCode!Q: unsure but its redundant
• wordle_yvaniak: unsure but redundant
• grp: intended as documented but redundant