I actually have an idea about this problem: Make `try!` applicable to
non-`Result` values:
~~~~
pub trait Try<T> {
fn into_result(self) -> Result<T,Self>;
}
impl<T> Try<T> for Option<T> {
#[inline]
fn into_result(self) -> Result<T,Option<T>> {
match self { Some(v) => Ok(v), None(v) => Err(None(v)) }
}
}
impl<T,E> Try<E> for Result<T,E> {
#[inline]
fn into_result(self) -> Result<T,Result<T,E>> {
match self { Ok(v) => Ok(v), Err(v) => Err(Err(v)) }
}
}
#[macro_export]
macro_rules! try(
($e:expr) => (match $e.into_result() { Ok(e) => e, Err(e) => return e })
)
~~~~
I'm not sure about the naming, but it may work.
2014-03-19 5:56 GMT+09:00 Phil Dawes <[email protected]>:
> Hello!
>
> I had my first github patch yesterday - Hatahet kindly cleaned up some code
> for me. I was using match to destructure the Option<uint> output from
> str.find_str(), but then doing nothing with the None case. He wrote:
>
> 'The match expression for options is good for when you want to deal with
> both cases of the Option type -- namely Some and None. If you only deal with
> Some, then you can cut down on some redundancy by using Option.map() or
> Option.iter().'
>
> https://github.com/phildawes/racer/pull/1
>
> so all the instances of
>
> match line.find_str(..) {
> Some(n) => {
> ...
> }
> None => {}
> }
>
> became:
>
> for n in line.find_str(..).move_iter() {
> ...
> }
>
> Which is much more consise and so I applied the patch.
>
> However now reading it again I find using 'for' in this way a bit confusing
> because it says to me that there are potentually multiple results to the
> find_str() method (implying that it finds multiple matches of the string
> when really it does not).
>
> Using map looks is less confusing to my eyes, but it feels hacky because I'm
> discarding the result and I guess is still imply iteration over multiple
> results:
>
> line.find_str(..).map(|n|{
> ...
> });
>
> Is there a clearer way?
>
> Thanks,
>
> Phil
>
>
> _______________________________________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/rust-dev
>
--
-- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/
-- Opinions expressed in this email do not necessarily represent the
views of my employer.
--
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
