New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(builder): Custom parser for arg values #3732
Commits on May 12, 2022
-
-
refactor(parser): Track str/OsStr values via Box
Unfortunately, we can't track using a `ValueParser` inside of `Command` because its `PartialEq`. We'll have to wait until a breaking change to relax that. Compatibility: - We now assert on using the wrong method to look up defaults. This shouldn't be a breaking change as it'll assert when getting a real value. - `values_of`, et al delay panicing on the wrong lookup until the iterator is being processed.
Commits on May 16, 2022
-
feat(parser): Add type information to arg values
To set the type, we offer - `ValueParser::<type>` short cuts for natively supported types - `TypedValueParser` for fn pointers and custom implementations - `value_parser!(T)` for specialized lookup of an implementation (inspired by clap-rs#2298) The main motivation for `value_parser!` is to help with `clap_derive`s implementation but it can also be convinient for end-users. When reading, this replaces nearly all of our current `ArgMatches` getters with: - `get_one`: like `value_of_t` - `get_many`: like `values_of_t` It also adds a `get_raw` that allows accessing the `OsStr`s without panicing. The naming is to invoke the idea of a more general container which I want to move this to. The return type is a bit complicated so that - Users choose whether to panic on invalid types so they can do their own querying, like `get_raw` - Users can choose how to handle not present easily (clap-rs#2505) We had to defer setting the `value_parser` on external subcommands, for consistency sake, because `Command` requires `PartialEq` and `ValueParser` does not impl that trait. It'll have to wait until a breaking change. Fixes clap-rs#2505
-
-
feat(parser): Expose env-like bool parsers
Still unsure what should be the default but this at least makes it easier for people to choose.
-
-
-
-
-
-
-
-
refactor(parser): Tweak specialization precedence
In theory, directly implemented types should have higher precedence than inferring from another trait.
-
-
-
-
feat(parser): Track ValueParser's possible values
This will let us replace `Arg::possible_values` completely by letting completions check these.
-
-
-
doc(parser): Expand examples for ValueParser
This identified a problem with the blanket implementations for `TypedValueParser`: it only worked on function pointer types and not unnamed function tupes. The user has to explicitly decay the function type to a function pointer to opt-in, so I changed the blanket impl. The loss of the `OsStr` impl shouldn't be too bad.
-
-
refactor(parser): Make AnyValue opaque
This gives a little more implementation flexibility
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
fix(parser): Be consistently strict with ArgMatches types
This gives us more implementation freedom for the future.
-
feat(parser): Allow removing values from ArgMatches
This allows reducing the use of `Clone`, especially in `clap_derive`.
-
-
-
-
feat(parsr): Expose all built-in TypedValueParsers
This makes life easier for people, whether they want a geneirc `NonEmpty<impl TypedValueParser>` or a `PathBufExists(PathBuf)`.
Commits on May 17, 2022
-
feat(parser): Convenient range value parsers
There are several approaches with this - `value_parser(N..M)`: creates an i64 range - `value_parser(value_parser!(u16).range(10..))`: creates an u16 range that starts at 10 - `RangeI64ValueParser`: create whatever range you want I was hoping to generalize `RangeI64ValueParser` for any source type, not just i64, but ran into issues and decided to punt. I chose `i64` as the source type as it seemed the most general and didn't run into portability issues like `isize`. This is a step towards clap-rs#3199. All that is left is for the derive to use this.
-
-
-
-
-
-
This is needed for `Bound::cloned` and fits within official MSRV policy (2 versions back) and unofficial (6 months, see clap-rs#3267)