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.
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 #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 (#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#2505
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.
The top-level API for clap is getting a bit bloated. By exposing these
modules, we'll be able to continue to add new, less commonly used types
while keeping the main API focused.
