-
Notifications
You must be signed in to change notification settings - Fork 63
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
implement opt_get() method call on Matches. #70
Conversation
prataprc
commented
May 22, 2018
- more tolerant than opt_default.
- folds str::parse() on the argument and returns Result<T,E>.
src/lib.rs
Outdated
/// Similar to opt_default, except the two differences. Instead of | ||
/// returning None when option was not present, return `def`. Instead of | ||
/// returning &str slice return valued of type T parsed using str::parse(). | ||
pub fn opt_get<T>(&self, nm: &str, def: T) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a good addition to me! What do you think about having two methods here:
pub fn opt_get<T>(&self, nm: &str) -> Result<Option<T> T::Err>;
pub fn opt_get_default<T>(&self, nm: &str, def: T) -> Result<T: T::Err>;
so that we can still use this method in cases where there isn't an obvious default to use?
The Result<Option>
signature is a little weird, but chances are you'd blow up on the result, and branch on the option:
match matches.opt_get("name")? {
Some(opt) => { ... },
None => { ... }
}
Or maybe:
let opt = matches.opt_get("name").unwrap_or_else(|e| {
println!("invalid value for `name`: {}", e);
...
process::exit(1)
});
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By T::Err in the Result<> did you mean ::Err ? Or is that
something new ?
so that we can still use this method in cases where there isn't an obvious
default to use?
In these cases won't opts_str, opt_str and opt_default be useful ? I haven't
really used getopts much, so I am not able to judge which is more ergonomic ..
Cheers,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, by T::Err
I mean the associated error type on the FromStr
trait, like you have currently. We should actually be able to just say T::Err
instead of <T as FromStr>::Err
because all we know about T
from the where
clause is that it implements FromStr
.
If you use opt_str
you'll still need to do the FromStr
conversion yourself, so having opt_get
without a default is closer to how opt_str
works already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
* more tolerant than opt_default. * folds str::parse() on the argument and returns Result<T,E>.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me! Thanks @prataprc.