clap/examples/tutorial_builder/02_app_settings.rs

use clap::{arg, command, ArgAction};

fn main() {
    let matches = command!() // requires `cargo` feature
        .allow_negative_numbers(true)
        .arg(arg!(--two <VALUE>).action(ArgAction::Set))
        .arg(arg!(--one <VALUE>).action(ArgAction::Set))
        .get_matches();

    println!(
        "two: {:?}",
        matches.get_one::<String>("two").expect("required")
    );
    println!(
        "one: {:?}",
        matches.get_one::<String>("one").expect("required")
    );
}
fix(help)!: Make `DeriveDisplayOrder` the default, removing it Force sorting with `next_display_order(None)` Fixes #2808 2022-07-22 20:43:49 +00:00			`use clap::{arg, command, ArgAction};`
docs: Re-work examples This creates distinct tutorial examples from complex feature examples (more how-tos). Both sets are getting builder / derive versions (at least the critical ones). 2021-11-30 18:30:19 +00:00
			`fn main() {`
docs: Move everything to docs.rs A couple of things happened when preparing to release 3.0 - We needed derive documentation - I had liked how serde handled theres - I had bad experiences finding things in structopt's documentation - The examples were broken and we needed tests - The examples seemed to follow a pattern of having tutorial content and cookbook content - We had been getting bug reports from people looking at master and thinking they were looking at what is currently released - We had gotten feedback to keep down the number of places that documentation was located From this, we went with a mix of docs.rs and github - We kept the number of content locations at 2 rather than 3 by not having an external site like serde - We rewrote the examples into explicit tutorials and cookbooks to align with the 4 styles of documentation - We could test our examples by running `console` code blocks with trycmd - Documentation was versioned and the README pointed to the last release This had downsides - The tutorials didn't have the code inlined - Users still had a hard time finding and navigating between the different forms of documentation - In practice, we were less likely to cross-link between the different types of documentation Moving to docs.rs would offer a lot of benefits, even if it is only designed for Rust-reference documentation and isn't good for Rust derive reference documentation, tutorials, cookbooks, etc. The big problem was keeping the examples tested to keep maintenance costs down. Maybe its just me but its easy to overlook - You can pull documentation from a file using `#[doc = "path"]` - Repeated doc attributes get concatenated rather than first or last writer winning Remember these when specifically thinking about Rust documentation made me realize that we could get everything into docs.rs. When doing this - Tutorial code got brought in as was one of the aims - We needed to split the lib documentation and the README to have all of the linking work. This allowed us to specialize them according to their rule (user vs contributor) - We needed to avoid users getting caught up in making a decision between Derive and Builder APIs so we put the focus on the derive API with links to the FAQ to help users decide when to use one or the other. - Improved cross-referencing between different parts of the documentation - Limited inline comments were added to example code - Introductory example code intentionally does not have teaching comments in it as its meant to give a flavor or sense of things and not meant to teach on its own. This is a first attempt. There will be a lot of room for further improvement. Current know downsides: - Content source is more split up for the tutorials This hopefully addresses #3189 2022-07-19 18:29:31 +00:00			let matches = command!() // requires `cargo` feature
feat: Replace core set of AppSettings with functions This is a part of #2717 Some settings didn't get getters because - They are transient parse settings (e.g. ignore errors) - They get propagated to args and should be checked there `is_allow_hyphen_values_set` is a curious case. In some cases, we only check the app and not an arg. This seems suspicious. 2022-02-10 17:51:40 +00:00			`.allow_negative_numbers(true)`
fix(parser): Deprecate args_override_self This shouldn't be needed anymore now that this is effectively the new behavior for the non-deprecated actions. This was briefly talked about in https://github.com/clap-rs/clap/discussions/2627 but I wasn't familiar enough with the implementation to know how safe it is. Now, maintainrs and users can be more confident because they are explicitly opting into it. See also #3795 2022-06-06 19:55:43 +00:00			`.arg(arg!(--two <VALUE>).action(ArgAction::Set))`
			`.arg(arg!(--one <VALUE>).action(ArgAction::Set))`
docs: Re-work examples This creates distinct tutorial examples from complex feature examples (more how-tos). Both sets are getting builder / derive versions (at least the critical ones). 2021-11-30 18:30:19 +00:00			`.get_matches();`

docs(example): Update for value_parser 2022-05-23 15:50:11 +00:00			`println!(`
			`"two: {:?}",`
fix(parser): Simplify the common getter API Clap has focused on reporting development errors through assertions rather than mixing user errors with development errors. Sometimes, developers need to handle things more flexibly so included in #3732 was the reporting of value accessor failures as internal errors with a distinct type. I've been going back and forth on whether the extra error pessimises the usability in the common case vs dealing with the proliferation of different function combinations. In working on deprecating the `value_of` functions, I decided that it was going to be worth duplicating so long as we can keep the documentation focused. 2022-05-25 15:46:42 +00:00			`matches.get_one::<String>("two").expect("required")`
docs(example): Update for value_parser 2022-05-23 15:50:11 +00:00			`);`
			`println!(`
			`"one: {:?}",`
fix(parser): Simplify the common getter API Clap has focused on reporting development errors through assertions rather than mixing user errors with development errors. Sometimes, developers need to handle things more flexibly so included in #3732 was the reporting of value accessor failures as internal errors with a distinct type. I've been going back and forth on whether the extra error pessimises the usability in the common case vs dealing with the proliferation of different function combinations. In working on deprecating the `value_of` functions, I decided that it was going to be worth duplicating so long as we can keep the documentation focused. 2022-05-25 15:46:42 +00:00			`matches.get_one::<String>("one").expect("required")`
docs(example): Update for value_parser 2022-05-23 15:50:11 +00:00			`);`
docs: Re-work examples This creates distinct tutorial examples from complex feature examples (more how-tos). Both sets are getting builder / derive versions (at least the critical ones). 2021-11-30 18:30:19 +00:00			`}`