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(parser): Check if args were present #3382

Merged
merged 1 commit into from Feb 1, 2022
Merged

Conversation

epage
Copy link
Member

@epage epage commented Feb 1, 2022

In clap2, ArgMatches.args was public but hidden. We made it private
in clap3, giving us more implementation flexibility but many people
relied on it, like to short-circuit defaulting, providing their own
ArgRequiredElseHelp, etc.

The main problem was how to expose this

  • If we think of ArgMatches as a container (a DAG), should we have an
    is_empty and what all is included in that, like subcommands?
  • If we focus on only args, what term how do we refer to this to convey
    the right intent?

In the end, I realized that this aligns most with our existing
is_present check and reporting if args are present fits the best
within the existing API.

I looked into also exposing iterating over the args (present_arg_ids)
but we have no way to expose the Id. The Id is currently private and if
we made it public, it can't be used to access any arg because it can't
implement Key.

This supersedes #3265

In clap2, `ArgMatches.args` was public but hidden.  We made it private
in clap3, giving us more implementation flexibility but many people
relied on it, like to short-circuit defaulting, providing their own
`ArgRequiredElseHelp`, etc.

The main problem was how to expose this
- If we think of `ArgMatches` as a container (a DAG), should we have an
  `is_empty` and what all is included in that, like subcommands?
- If we focus on only args, what term how do we refer to this to convey
  the right intent?

In the end, I realized that this aligns most with our existing
`is_present` check and reporting if args are present fits the best
within the existing API.

I looked into also exposing iterating over the args (`present_arg_ids`)
but we have no way to expose the Id.  The Id is currently private and if
we made it public, it can't be used to access any arg because it can't
implement `Key`.

This supersedes clap-rs#3265
@epage epage merged commit 8e807c2 into clap-rs:master Feb 1, 2022
@epage epage deleted the matches branch February 1, 2022 22:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant