Hard to know how to respond to 3.2.0 deprecation messages in the derive API

[Alexhuszagh]

Maintainer's note:

• As of 3.2.3, deprecations are behind the deprecated feature which is off by default for now (see fix: Allow people to opt-in to deprecations #3830)
• Until we improve the messages (if someone steps up to do so), See the release announcement for more details on the deprecations and cargo-deny for an example of how to migrate to clap 3.2 (with a tl;dr).
  • One simple way of reducing the messages is opting into unstable-v4 feature in your Cargo.toml. See the changelog for what else this affects.
• Explanation of assumptions and circumstances that got us here

---

Please complete the following tasks

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

Rust Version

rustc 1.61.0 (fe5b13d68 2022-05-18)

Clap Version

3.2.1 (or 3.2.0)

Minimal reproducible code

main.rs

use clap::{Parser, Subcommand};

#[derive(Parser, Debug)]
#[clap(version, about, long_about = None)]
struct Cli {
    #[clap(subcommand)]
    command: Commands,
}

#[derive(Subcommand, Debug)]
enum Commands {
    /// Simple Command.
    GetArgs {
        /// Provide verbose diagnostic output.
        #[clap(short, long)]
        verbose: bool,
        /// Sample optional string.
        #[clap(long)]
        value: Option<String>,
        /// Just a list of valies
        list: Vec<String>
    },
}

fn main() {
    let cli = Cli::parse();
    match &cli.command {
        Commands::GetArgs { verbose, value, list } => {
            println!("verbose={:?}", verbose);
            println!("value={:?}", value);
            println!("list={:?}", list);
        }
    }
}

Cargo.toml

[package]
name = "test"
version = "0.1.0"
edition = "2021"

[dependencies]
clap = { version = "3.2.1", features = ["derive"] }

Steps to reproduce the bug with the above code

Use clap >= 3.2.0, this does not produce any warnings in 3.1.18.

cargo build

Actual Behaviour

warning: use of deprecated unit variant `clap::ArgAction::StoreValue`: Replaced with `ArgAction::Set` or `ArgAction::Append`
  --> src/main.rs:17:9
   |
17 | /         /// Sample optional string.
18 | |         #[clap(long)]
19 | |         value: Option<String>,
   | |_____________________________^
   |
   = note: `#[warn(deprecated)]` on by default

warning: use of deprecated unit variant `clap::ArgAction::StoreValue`: Replaced with `ArgAction::Set` or `ArgAction::Append`
  --> src/main.rs:20:9
   |
20 | /         /// Just a list of valies
21 | |         list: Vec<String>
   | |_________________________^

warning: use of deprecated associated function `clap::ArgMatches::is_present`: Replaced with either `ArgAction::SetTrue` or `ArgMatches::contains_id(...)`
  --> src/main.rs:16:18
   |
16 |         verbose: bool,
   |                  ^^^^

warning: use of deprecated associated function `clap::Arg::<'help>::validator`: Replaced with `Arg::value_parser(...)`
  --> src/main.rs:17:9
   |
17 | /         /// Sample optional string.
18 | |         #[clap(long)]
19 | |         value: Option<String>,
   | |_____________________________^

warning: use of deprecated associated function `clap::Arg::<'help>::multiple_occurrences`: Replaced with `Arg::action` (Issue #3772)
  --> src/main.rs:21:15
   |
21 |         list: Vec<String>
   |               ^^^^^^^^^^^

warning: use of deprecated associated function `clap::Arg::<'help>::validator`: Replaced with `Arg::value_parser(...)`
  --> src/main.rs:20:9
   |
20 | /         /// Just a list of valies
21 | |         list: Vec<String>
   | |_________________________^

warning: `clap` (bin "clap") generated 6 warnings
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/clap get-args`

Expected Behaviour

None of these warnings should occur, I believe.

Additional Context

No response

Debug Output

The debug output is the same as the above output.

[epage]

These deprecation warnings are intentional though, due to the derive API wrapping the builder API, the fix might not be as obvious. We do expect to be adding deprecations every minor release and we recommend not blocking CI on this as the toil adds backpressure on crates to not evolve their API. See the 3.1 announcement for details on this.

See the release announcement for more details on the deprecations and cargo-deny for an example of how to migrate to clap 3.2 (with a tl;dr).

[Emilgardis]

So how does one fix the deprecation warnings with the above sample code?

nvm, follow the tldr in cargo-deny

[CraZySacX]

Shouldn't non-deprecated code be "selected" per the docs: When not present: will auto-select an implementation based on the field type

Based off of this I assumed value-parser is always used, but it seems to use deprecated code when I don't have it explicitly specified.

[Alexhuszagh]

So how does one fix the deprecation warnings with the above sample code?

Change everything to say, #[clap(value_parser), which clutters up everything. See this.

[epage]

Shouldn't non-deprecated code be "selected" per the docs: When not present: will auto-select an implementation based on the field type

The problem is the new behavior is a breaking change, so you need to opt-in to it. In clap 4.0, we'll make it the default.

Change everything to say, #[clap(value_parser), which clutters up everything.

Yes, it clutters things up but it also let's you start testing with the clap 4.0 behavior and provide feedback. If you would rather wait, you also always allow these deprecations.

[Alexhuszagh]

Shouldn't non-deprecated code be "selected" per the docs: When not present: will auto-select an implementation based on the field type

The problem is the new behavior is a breaking change, so you need to opt-in to it. In clap 4.0, we'll make it the default.

Maybe change the deprecation warnings then in the derive API? Use #[allow(deprecated)] and then change the deprecation warning so you mention the default behavior is changing, and mention that the default behavior is changing in 4.0, you probably want to add value_parser? These deprecation notices are relatively opaque since they reference a different API than the one currently used, and have no mention of how they arise.

I'm glad to at least see the default behavior will change.