Skip to content
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(derive): Allow users to opt-in to ValueParser #3742

Merged
merged 13 commits into from May 23, 2022
Merged

Conversation

epage
Copy link
Member

@epage epage commented May 23, 2022

For clap 3, its opt-in as a precaution against breaking
compatibility in some weird cases. We made this easy by just specifying #[clap(value_parser)] which will default to value_parser(value_parser!(T)).

This does require the types to implement Clone since the Arc might have copies made.

In doing this, some bugs / inccompleteness of value_parser was observed and fixed

  • Not showing possible values from value parser in help
  • Range errors didn't show the correct range

Deprecations were deferred out of this to keep it smaller.

Fixes #3731
Fixes #3496
Fixes #3589

epage added 13 commits May 18, 2022 09:10
Right now, the aliasing is safe (the compiler says so!) but we're going
to be switching to a `&mut` and need to ensure we don't alias.
In case the `ArgMatches` is cloned, this forces a constraint that the
underlying type impls `Clone` but that should be safe as we only support
`String` and `OsString`.
For clap 3, its opt-in as a precaution against breaking
compatibility in some weird cases.

This does require the types to implement `Clone`.

Fixes clap-rs#3734
Fixes clap-rs#3496
Fixes clap-rs#3589
Only bothered to implement this for `value_parser` cases as `parse`
cases are going to be considered deprecated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant