Add has_no_matched_args to ArgMatches
#3265
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ohsayan
force-pushed
the
argmatches/has_no_matched_args
branch
from
a9593b1 to
d2909aa
Compare
This member function provides a simple way to check if no arguments were matched at all, in v3. The same in v2 could be achieved by accessing the `args` field in `ArgMatches` and checking if it was empty. However, in v3 the field was made private in the public API and for the same reason, this method was added.
ohsayan
force-pushed
the
argmatches/has_no_matched_args
branch
from
d2909aa to
0fc3fcb
Compare
ohsayan
added a commit
to skytable/skytable
that referenced
this pull request
Jan 6, 2022
All deps except for `clap` has been upgraded. Due to the removal of the `args` field in `ArgMatches` in v3, and our dependence on the field, we cannot upgrade to the latest version. A PR has been created and once it is merged or a workaround suggested, we can upgrade. (see clap-rs/clap#3265)
epage
added a commit
to epage/clap
that referenced
this pull request
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 clap-rs#3265
|
How to represent this in the abstraction was my biggest concern (which included understanding how it'd be used). I was exploring how this should be done and created #3382 which is now available in v3.0.14. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This member function provides a simple way to check if no arguments
were matched at all, in v3. The same in v2 could be achieved by
accessing the
argsfield inArgMatchesand checking if it wasempty. However, in v3 the field was made private in the public API
and for the same reason, this method was added.