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

Add support for typed argument values #72

Closed
kbknapp opened this issue Apr 14, 2015 · 2 comments · Fixed by #74
Closed

Add support for typed argument values #72

kbknapp opened this issue Apr 14, 2015 · 2 comments · Fixed by #74
Labels
C-enhancement Category: Raise on the bar on expectations

Comments

@kbknapp
Copy link
Member

kbknapp commented Apr 14, 2015

Initially support Int, and Float. Implementation should allow additions down the road as well, based on usage, maybe a File or Directory too...

@kbknapp kbknapp added C-enhancement Category: Raise on the bar on expectations feature request labels Apr 14, 2015
@kbknapp
Copy link
Member Author

kbknapp commented Apr 14, 2015

Initial implementation may simply be a convenience macro, something like

let num = value_t!(matches.value_of("length"), u32);

This would allow far more types initially simply using Rust's &str.parse(), without crossing any lines (i.e where does clap validation stop, and developer validation start? What about parsing IP address, MAC addresses, etc....where is the line?). The more validation clap does, the bigger a performance hit everyone takes whether they want the validation or not.

What's unclear is if failure to parse should constitute ending the process? I'm leaning towards returning an Option<T> or Result<T,&str> which gives clap consumers the option to use .unwrap_or() for a default, or also deciding what to do upon a failed parse. I'm going to continue thinking about this before implementing...

The other nice thing about a macro initially is I could potentially include something like a decode_t! to decode a &str into a user defined enum. Now this would open the door for changing .possible_values() but I'm unsure about how to best implement this part without just requiring the consumer to manually type out each possibility of the enum into a possible values vec as is currently done.

kbknapp added a commit that referenced this issue Apr 14, 2015
Adds convenience macros to get typed values

Closes #72
@kbknapp
Copy link
Member Author

kbknapp commented Apr 14, 2015

While this isn't the best solution, it does work for the time being. I'm still unsure how to best implement this in a way that is least taxing on the developer (i.e. I don't want to force people to implement custom traits, or anything like that...)

So this will remain TBD, but for now value_t! and value_t_or_exit! will at least get the job done in a somewhat efficient manner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: Raise on the bar on expectations
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant