The binary size and performance difference is enough to make it
configurable.
Code size:
- default: 565.7 KiB
- perf: 578.5 KiB
Build time:
- default: 9.1706 us
- perf: 7.0479 us
Parse time:
- default: 12.673 us
- perf: 8.1708 us
Parse with subcommand time:
- default: 12.112 us
- perf: 7.9874 us
Another step towards #1041
This isn't the long term type for `PossibleValue::help`, I just wanted
to get the lifetime out of the way first before figuring out how help
will work.
While `TypedValueParser` will generally make it easier to reuse value
parsers, this was particularly written for flags. Besides having a
concrete API to document, an advantage over `fn(&str) -> Result<bool, E>`
value parsers is you get all of the benefits of the existing value
parsers for environment variable parsing.
The main breakinge change cases:
- `&[char]`: now requires removing `&`
- All other non-ID `&[_]`: hopefully #1041 will make these non-breaking
Fixes#2870
For now, we are focusing only on iterating over the argument ids and not
the values.
This provides a building block for more obscure use cases like iterating
over argument values, in order. We are not providing it out of the box
at the moment both to not overly incentize a less common case, because
it would abstract away a performance hit, and because we want to let
people experiment with this and if a common path emerges we can consider
it then if there is enough users.
Fixes#1206
Now that `Id` is public, we can have `ArgMatches` report them. If we
have to choose one behavior, this is more universal. The user can still
look up the values, this works with groups whose args have different
types, and this allows people to make decisions off of it when otherwise
there isn't enogh information.
Fixes#2317Fixes#3748
This is a step towards #1041
- `ArgGroup` no longer takes a lifetime
- One less field type needs a lifetime
For now, we are using a more brute force type (`String`) so we can
establish performance base lines. I was torn on whether to use `&str`
everywhere or make an `IdRef`. The latter would add a lot of noise that
I'm concerned about, so i left it simple for now. `IdRef` would help to
communicate the types involved though.
Speaking of communicating types, I'm also torn on whether we should use
`Id` for all strings or if we should have `Id`, `Name`, etc types to
avoid people mixing and matching.
This added 18.7 KB.
Compared to `HEAD~` on `06_rustup`:
- build: 6.23us -> 7.41us
- parse: 8.17us -> 9.36us
- parse_sc: 7.65us -> 9.29us
