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

Allow iterating over ArgMatches and check whether a match uses default value #2759

Closed
2 tasks done
romange opened this issue Sep 9, 2021 · 2 comments
Closed
2 tasks done

Comments

@romange
Copy link

romange commented Sep 9, 2021

Please complete the following tasks

  • I have searched the discussions
  • I have searched the existing issues

Clap Version

3.0.0-beta

Describe your use case

Use case: I would like to merge ArgMatches into Config settings using the following rules:

  1. ArgMatches have higher precedence over Config if they are explicitly set.
  2. If config setting is present but ArgMatches has an argument with default value then config value is taken.
  3. If config does not set the setting, then ArgMatches default value it taken.

In order to do this, I would need to iterate over ArgMatches.args and query MatchedArg.ty field.

Describe the solution you'd like

Some sort of interface that allows me to do this.

Alternatives, if applicable

Currently, I have to declare all fields in clap structure with Option<> and without default values in order to expose similar semantics. For example,

struct MyOpts {
    #[clap(short, long, default_value="80")]
    port: Option<u16>,
}

instead of

struct MyOpts {
    #[clap(short, long, default_value="8080")]
    port: u16,
}

Additional Context

No response

@epage
Copy link
Member

epage commented Sep 9, 2021

While, in general, I think there is value in

  • Allowing iterating
  • exposing ArgType (though maybe giving it a more meaningful name, like ArgSource

For layered config, I'm a bit unsure on this approach. I've split layered config talk out to a discussion

@pksunkara
Copy link
Member

pksunkara commented Sep 23, 2021

This issue is a duplicate of #1206 and thus we are closing this.

I would appreciate if you could tell us more about why you were not able to find the original issue. You marked that you have searched the existing issues. What search terms did you use?

This questions is asked in the attempt to understand if there are any other contexts/cases related to the issue that we missed discussing originally.

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

No branches or pull requests

3 participants