When overriding other fields, help or version flag, globals, etc, a user
might not care about the value, so let's ignore the lookup.
Been talking about this for a while but Issue #4367 moved this forward
because there wasn't a good way to handle this without changing
behavior.
If the inner type never implemented `group_id()`, then it won't work and
people will be confused. This at least gives people an idea of whats
going wrong.
This is most likely to be a problem until #3165 is fully implemented but
hand-implementations can still run into this. Probably should have made
the groups another trait to catch this in type system but too late.
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)
Originally, I saw the ideal as the parent command being isolated from
`#[clap(flatte)]` especially after all of the doc comment
leakage issues. We scaled that back to just `next_help_heading` because
of the issues with settling on a policy and maintenance to cover
everything. When doing `next_display_order`, we decided it would mess
things up too much to isolate it.
With #1807, we instead have been moving towards setting
`#[command(next_help_heading)]` anywhere, we just need to finish working
out how it should work.
Since the `name` is changed to be the package name, we can't use it as
(1) its not as predictable and (2) it can lead to conflicts if a
`Parser` is flattened into a `Parser`
When I removed these in v5, we didn't have a deprecation approach for
the derive and I didn't want to forget. Now we do have a deprecation
approach and that is the reminder, so we don't need to carry around v5
changes.
