Instead of just renaming it, I reconsidered what the API should look
like. A custom separator for author does not make sense positionally
but accepting a name, and defaulting it, does fit with what someone
would expect.
I removed the `_from_crate` suffix because it doesn't seem necessary.
We don't have this kind of naming for the derive. I feel it cleans
things up this way.
This is part of the `App` rename.
Previously, I was concerned about not being able to deprecate
For backwards compatibility, we still expose the `IntoApp` name.
No good solution for transitioning the trate name, unfortnately, since
we can't mark `use`s as deprecated (we can, it just does nothing).
I got rid of the `into` prefix because that implies a `self` parameter
that doesn't exist.
The long term goals are
- Easier refactoring
- Identify needs for reflection API
Shorter term, if I want to rename `App` to `Command` and deprecate
`App`, it will mark all member access as deprecated. This works around
that.
I gave up in exploring abstractions when it came to `MKeyMap` access.
This can be refined in the future.
The main goal is to allow centralizing some building logic currently
split between the parser and `App`. It depends on this logic.
As a side benefit, this allowed us to decouple some operations from `Parser` in `App`.
The main impact I can see is that we'll calculate the required once for
parsing a subcommand and once for validation.
We left them in the docs for a period of time to help people find docs
for code that was still in use. Balancing that with the need for clean
docs, it seems like 3.1 is an appropriate time to mark them hidden in
the docs.
Now that we can use `SubcommandRequired |
ArgRequiredElseHelp`, this setting offers little value but requires we
track required subcommands with two different settings. Deprecating as
the cost is not worth the benefit anymore.
Issue #3280 will see the derive updated
