For now, we are still treating `clap` as the user facing API for both
builder and derive, making this an internal change as we don't expect
this to negatively impact builder build times all that much. We can
re-evaluate at a later time and consider having distinct top-level
crates for builder and derive.
Looking at `--timings` on my machine
- `clap` only took 0.04s to build and it happened in
parallel to `clap_builder` codegen
- this saved 1.7s for derive build times, with `clap_builder` building
in parallel to `syn` and `clap_builder` and `clap_derive` finishing
around the same time.
This was discussed some at https://rust-lang.zulipchat.com/#narrow/stream/220302-wg-cli/topic/clap.20build.20times.20and.20.60clap_derive.60.3A.20a.20crazy.20idea
My guess is this was left over from switching to using the type based
API. The generated code for extracting values from `ArgMatches` had some
code that didn't actually do anything, like mapping over the identity
function, and wrapping a value in an `Ok` only to immediately use "?" on
it.
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.
