Additional parameter to validator function #1913
-
Is there any possibility to use in validator function additional parameter, I can see in sources that for now these functions only take one &str parameter but it would be handy for me to have possibility write function which has an additional parameter. Use case: I am writing a small CLI app for editing DNS records in external API service. One of the command is for example:
answer parameter is
type is DNS record type so for example A, MX, TXT etc. Now in valid_answer I would like to have somehow the possibility to check for which record type we are validating answers. There will be for example different rules for MX records: we demand number string format and different for A records: eg string string. I can always take matches and verify it later where I have all available parameters but maybe there's a way do this already in Builder patters. the version of clap 3.0 (latest). |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
In #1206 we discussed almost exactly this. Although the linked issue isn't strictly about this feature, it came up because it relates to what you're asking about. The idea for some kind of Map or Handler on an argument is the relevant comments. We haven't come to any consensus about that feature yet, so I'm not sure what direction we're going to take, if any, yet. For now, best practice is if your i.e. fn valid_answers(m: &ArgMatches) -> Result<(), String> {
// ... validate your args
} To the user of your binary it should feel effectively the same. |
Beta Was this translation helpful? Give feedback.
-
Thnx for your answers. I just did things suggested by You, works for me. |
Beta Was this translation helpful? Give feedback.
In #1206 we discussed almost exactly this. Although the linked issue isn't strictly about this feature, it came up because it relates to what you're asking about. The idea for some kind of Map or Handler on an argument is the relevant comments. We haven't come to any consensus about that feature yet, so I'm not sure what direction we're going to take, if any, yet.
For now, best practice is if your
validator
requires knowledge of other arguments it should be done after parsing completes in consumer code.i.e.
To the user of your binary it should feel effectively the same.