Announcing Rust 1.22

Re:Announcing Rust 1.22 by lower on Thursday November 23, 2017 @04:19AM (#15763892)

Suppose you have two functions

    fn f() -> Result<A, E>
    fn g() -> Result<B, E>

Then you can write

     fn h() -> Result<(A,B), E> {
        let x = f()?;
        let y = g()?;
        Ok((x, y))
     }

rather than having to do something like

    fn h() -> Result<(A,B), E> {
       match f() {
           Ok(x)  => {
             match g() {
               Ok(y)  => Ok((x,y)),
               Err(e) => Err(e)
             } 
           },
           Err(e) => Err(e),
       } 
     }

(written from memory, please excuse syntax errors)

What's new is that this also works with Option<A> now.

[ Parent | on HN ]

Re:Announcing Rust 1.22 by zZorgz on Thursday November 23, 2017 @07:33AM (#15764606)

As others mentioned, it looks equivalent to using the try! macro (which I'm not sure this is supposed to replace?)

Another sane alternative here is using and_then, map, etc.

Writing from memory too:

  fn h() -> Result<(A, B), E> {
    f().and_then(|x| g().map(|y| (x, y)))
  }

..which seems to be a different style of control flow to choose from. On one hand, I suppose one may avoid using and_then with code dealing with side effects. On another hand, ? seems restricted to being used inside functions that have to return a a single type (like Result) they operate on.

[ Parent | on HN ]

Re:Announcing Rust 1.22 by steveklabnik on Thursday November 23, 2017 @07:40AM (#15764626)

? is explicitly a replacement for try!, yes.

> functions that have to return a single type

Well, all functions have to return a single type, though that type may be a composite type, like a tuple.

Less pedantically, `?` lets you (well, will let you) unwrap values and convert their error cases between each other. So once the next round of stabilization happens, if you have a function that returns Results, you can mix ? on Options and Results in the body, and vice versa. And it can be extended for other types too. Basically, it's an early return "protocol" if you will.

[ Parent | on HN ]

Re:Announcing Rust 1.22 by zZorgz on Thursday November 23, 2017 @07:51AM (#15764676)

By single type, I meant to hint not being able to mix ? on Options and Results in the body, but good to know that's soon possible! Though you still can't, eg, use `?` in main()

[ Parent | on HN ]

Re:Announcing Rust 1.22 by kibwen on Thursday November 23, 2017 @10:00AM (#15765425)

Tracking issue for using it in main: https://github.com/rust-lang/rust/issues/43301

[ Parent | on HN ]

Re:Announcing Rust 1.22 by mmstick on Tuesday November 28, 2017 @02:26PM (#15800532)

You can mix them if you take your Options and convert them into Results with the Option::ok_or(E) method.

    do_this(x).ok_or(CustomError::ThisError)?;

[ Parent | on HN ]

Re:Announcing Rust 1.22 by zZorgz on Thursday November 23, 2017 @08:09AM (#15764774)

Also regarding an "early return protocol", I'd also be curious for continue, break, any ! type expression. For one of the Rust projects I worked on, I wrote an unwrap macro on Option that takes a secondary ! argument.

[ Parent | on HN ]

Re:Announcing Rust 1.22 by steveklabnik on Thursday November 23, 2017 @08:05AM (#15764747)

That's coming as well!

[ Parent | on HN ]

Re:Announcing Rust 1.22 by zZorgz on Thursday November 23, 2017 @01:29PM (#15766925)

Interesting. Looking at the proposal it seems specific to main() and not any void returning function, by automatically picking an exit status. I suppose I worry the construct has a lack of control (log diagnostics, exit status, cleaning, etc) when bailing and can’t handle eg continue, break too.

[ Parent | on HN ]

Re:Announcing Rust 1.22 by steveklabnik on Thursday November 23, 2017 @02:27PM (#15767274)

exit status and cleaning should be just fine, logging or something else would need to not do it, yeah. continue and break would be weird outside of loops.

[ Parent | on HN ]