I'm a bit disappointed we don't have a way to control the action for the
help subcommand. Instead, people will need to provide their own and
disable ours. Long term, I want to design actions for subcommands but I
don't think its worth keeping `NoAutoHelp` around for it.
We aren't enumerating arguments but values for an argument, so the name
should reflect that.
This will be important as part of #1807 when we have more specific
attribute names.
For programs opting into the clap v4 behavior (with `action` or
`value_parser` attributes), we'll no longer generate a
`multiple_occurrences(true)` call in preparation for deprecating
`multiple_occurrences`. See #3772.
This mostly exist for
- Knowing of the value came from the command-line but we now have
`ArgMatches::source`
- Counting the number of flags but we now have `ArgAction::Count`
This shouldn't be needed anymore now that this is effectively the new
behavior for the non-deprecated actions.
This was briefly talked about in
https://github.com/clap-rs/clap/discussions/2627 but I wasn't familiar
enough with the implementation to know how safe it is. Now, maintainrs
and users can be more confident because they are explicitly opting into
it.
See also #3795
Dropping these will help simplify a lot, including removing of
occurrences.
These come at the cost of the derive not yet supporting types that impl
`From`.
This is the derive support for #3774 (see also #3775, #3777)
This combined with `value_parser` replaces `parser`. The main
frustration with this is that `ArgAction::Count` (the replacement for
`parse(from_occurrences)` must be a `u64`. We could come up with a
magic attribute that is meant to be the value parser's parsed type. We
could then use `TryFrom` to convert the parsed type to the user's type
to allow more. That is an exercise for the future. Alternatively, we
have #3792.
Prep for this included
- #3782
- #3783
- #3786
- #3789
- #3793
This is a follow up to #3420. Its easy to overlook this because it is only
useful for the conditionals (we actually prevent applying unconditional
defaults to unconditional requireds). This became apparent with the
increased use of defaults with `SetTrue`.
As always, there is the question of when is a bug fix a breaking change.
I'm going to consider this safe since we prevent some instances of this
from even happening and we already did #3420 and this is in line with
those.
Originally I hid all, assuming the flag-only use case but we had to
prevent that from showing up anyways. For the takes_value case, we
should be showing something since we know what it accepts. I decided to
only show the most basic values and hide the rest so as to not overwhelm
the user with redundant options and hope the user recognizes they are
redundant.
Now that flags can have meaningful defaults and with defaults being
implicitly set for certain actions, they appear in help but don't quite
make sense.
