Things that tripped up a user
- Derive reference was misunderstood to say that the only alternative to
the built-in value parser behavior was to implement
`ValueParserFactory`
- We now delegate to `value_parser!`s docs any talk of integrating
into it (it should have been a subbullet of "not present" anyways)
- `value_parser!` relies too much on the example to demonstrate behavior
when the user will likely make the determination of whether its
relevant before then
- We are now more upfront what type mappings are supported
- Too many steps to find all information
- For example, a user needs to look at `TypedValueParser`
implementations, `ValueParserFactory` implementations, and `From<T>
for ValueParser` implementations to understand what all can be used
- We are now more upfront with a lot of this information at the entry
points the user is most likely to look at
In addition, I did an audit of the docs to make sure they were updated
for us only supporting the new behavior and all of the new APIs.
See https://www.reddit.com/r/rust/comments/xjlie4/preannouncing_clap_40_a_rust_cli_argument_parser/ip9kzf1/
`clap::Error::raw` was producing ambiguity errors with a default generic
parameter on `clap::error::Error` (which `clap::Error` is a re-export
of).
I tried making `clap::Error` a type alias with a default generic
parameter but that ran into an ambiguity error with `map_err`.
So I'm going ahead and hard coding `clap::Error`. We don't expect
people to change this all that often.
This takes off another 14 KiB when color us not used. My hope is that
we'll be able to switch away from `termcolor` to a term styling crate
that will make this work in the color case as well.
This is a cheap pass at creating this to allow cutting out the cost of
rich error information / programmatic error information.
This cuts about 20 KiB off of the binary.
There is more we could cut out, like collecting of used arguments for
the usage, but I want to keep the conditionals simple.
Originally, clap carried a lifetime parameter. When moving away from
that, we took the approach that dynamically generated strings are always
supported and `&'static str` was just an optimization.
The problem is the code size increase from this is dramatic. So we're
taking the opposite approach and making dynamic formatting opt-in under
the `string` feature flag. When deciding on an implementation, I
favored the faster one rather than the one with smaller code size since
small code size can be gotten through other means.
Before: 567.2 KiB, 15.975 µs
After: 541.1 KiB, 9.7855 µs
With `string`: 576.6 KiB, 13.016 µs
The overall hope is to allow a `&'static str`-only version of clap, so
we need to move off of `Str` where dynamic strings are required. We
need it here for subcommands due to external subcommands.
This had minimal impact on code size (567.2 to 567.5 KiB)
