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

implement opt_get() method call on Matches. #70

Merged
merged 2 commits into from
Jun 28, 2018
Merged

implement opt_get() method call on Matches. #70

merged 2 commits into from
Jun 28, 2018

Conversation

prataprc
Copy link
Contributor

  • 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)
Copy link
Contributor

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?

Copy link
Contributor Author

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,

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

prataprc added 2 commits June 3, 2018 13:50
* more tolerant than opt_default.
* folds str::parse() on the argument and returns Result<T,E>.
Copy link
Contributor

@KodrAus KodrAus left a 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.

@KodrAus KodrAus merged commit 768eccf into rust-lang:master Jun 28, 2018
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

Successfully merging this pull request may close these issues.

None yet

2 participants