# Change Log All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](http://keepachangelog.com/) and this project adheres to [Semantic Versioning](http://semver.org/). ## [Unreleased] - ReleaseDate ### Highlights **`Arg::num_args(range)`** Clap has had several ways for controlling how many values will be captured without always being clear on how they interacted, including - `Arg::multiple_values(true)` - `Arg::number_of_values(4)` - `Arg::min_values(2)` - `Arg::max_values(20)` - `Arg::takes_value(true)` These have now all been collapsed into `Arg::num_args` which accepts both single values and ranges of values. `num_args` controls how many raw arguments on the command line will be captured as values per occurrence and independent of value delimiters. See [Issue 2688](https://github.com/clap-rs/clap/issues/2688) for more background. **Polishing Help** Clap strives to give a polished CLI experience out of the box with little ceremony. With some feedback that has accumulated over time, we took this release as an opportunity to re-evaluate our `--help` output to make sure it is meeting that goal. In doing this evaluation, we wanted to keep in mind: - Whether other CLIs had ideas that make sense to apply - Providing an experience that fits within the rest of applications and works across all shells Before: ``` git A fictional versioning CLI USAGE: git OPTIONS: -h, --help Print help information SUBCOMMANDS: add adds things clone Clones repos help Print this message or the help of the given subcommand(s) push pushes things stash ``` After: ``` A fictional versioning CLI Usage: git Commands: clone Clones repos push pushes things add adds things stash help Print this message or the help of the given subcommand(s) Options: -h, --help Print help information ``` - name/version header was removed because we couldn't justify the space it occupied when - Usage already includes the name - `--version` is available for showing the same thing (if the program has a version set) - Usage was dropped to one line to save space - Focus is put on the subcommands - Headings are now Title case - The more general term "command" is used rather than being explicit about being "subcommands" - The output is more dense with the expectation that it won't affect legibility but will allow more content - We've moved to a more neutral palette for highlighting elements (not highlighted above) In talking to users, we found some that liked clap's `man`-like experience. When deviating from this, we are making the assumption that those are more power users and that the majority of users wouldn't look as favorably on being consistent with `man`. See [Issue 4132](https://github.com/clap-rs/clap/issues/4132) for more background. **More Dynamicism** Clap's API has focused on `&str` for performance but this can make dealing with owned data difficult, like `#[arg(default_value_t)]` generating a String from the default value. Additionally, to avoid `ArgMatches` from borrowing (and for some features we decided to forgo), clap took the `&str` argument IDs and hashed them. This prevented us from providing a usable API for iterating over existing arguments. Now clap has switched to a string newtype that gives us the flexibility to decide whether to use `&'static str`, `Cow<'static, str>` for fast dynamic behavior, or `Box` for dynamic behavior with small binary size. As an extension of that work, you can now call `ArgMatches::ids` to iterate over the arguments and groups that were found when parsing. The newtype `Id` was used to prevent some classes of bugs and to make it easier to understand when opaque Ids are used vs user-visible strings. **Clearing Out Deprecations** Instead of doing all development on clap 4.0.0, we implemented a lot of new features during clap 3's development, deprecating the old API while introducing the new API, including: - Replacing the implicit behavior for args when parsing them with `ArgAction` - Replacing various one-off forms of value validation with the `ValueParser` API - Allowing derives to automatically do the right thing for `PathBuf` (allowing invalid UTF-8) - Replacing `AppSettings` and `ArgSettings` enums with getters/setters - Clarifying terms and making them more consistent ### Migrating Steps: 0. [Upgrade to v3](https://github.com/clap-rs/clap/blob/v3-master/CHANGELOG.md#migrating) if you haven't already 1. Add CLI tests (including example below), `-h` and `--help` output at a minimum (recommendation: [trycmd](https://docs.rs/trycmd/) for snapshot testing) 2. *If using Builder API*: Explicitly set the `arg.action(ArgAction::...)` on each argument (`StoreValue` for options and `IncOccurrences` for flags) 3. Run `cargo check --features clap/deprecated` and resolve all deprecation warnings 4. Upgrade to v4 5. Resolve compiler errors 6. Resolve behavior changes (see "subtle changes" under BREAKING CHANGES) 7. *At your leisure:* resolve new deprecation notices Example test (derive): ```rust #[derive(clap::Parser)] struct Cli { ... } #[test] fn verify_cli() { use clap::CommandFactory; Cli::command().debug_assert() } ``` Example test (builder): ```rust fn cli() -> clap::Command { ... } #[test] fn verify_cli() { cli().debug_assert(); } ``` Note: the idomatic / recommended way of specifying different types of args in the Builder API has changed: Before ```rust .arg(Arg::new("flag").long("flag")) # --flag .arg(Arg::new("option").long("option").takes_value(true)) # --option