Rust for C++ Programmers Part 7: Data Types

I'm curious why this isn't automatically destructured:

    struct IntPoint (int, int);

    fn foo(x: IntPoint) {
        let IntPoint(a, b) = x;  // Note that we need the name of the tuple
                                 // struct to destructure.

In Rust, we are quite strict about the syntax used for destructuring matching the syntax used for instantiation. There is a name in the tuple-struct declaration, therefore you must use the name when pattern matching (even though it is redundant).

What do you mean by "automatically destructured"? If you mean the extra step of destructuring in the function body, that's not necessary. You can destructure like that anywhere that a pattern is accepted, which includes function parameter lists:

  struct Foo(int, int);

  fn bar(Foo(a, b): Foo) {
      println!("a: {}, b: {}", a, b);
  }

  fn main() {
      let qux = Foo(1, 2);
      bar(qux);  // a: 1, b: 2
  }

Error handling in Rust is actually pretty awesome. There's a standard `Result` type. One can write a potentially fail-able function like:

    fn can_fail(arg: bool) -> Result {
        if arg {
            Ok(())
        } else {
            Err(StrBuf::from_str("Oops! Something went wrong."))
        }
    }

Here, there's no value when the function succeeds `()`. When it fails (I don't mean fail as in a `fail!()` or a panic or anything), you get a string back.

You can pattern match the return value:

    match can_fail(true) {
        Ok(_) => {},
        Err(err) => {}
    }

This can get quite cumbersome, however. That's why there's a `try!` macro that adds composability. The idea is that if you have a function returning a `Result`, wherever that function is being called could also return a `Result`.

     fn higher_up() -> Result {
         try!(can_fail(true));
     }

`try!` is simply:

    match $e { Ok(e) => e, Err(e) => return Err(e) }

This allows error to propagate up the chain.

When you're working in big-ish projects, it'd be best to have something better than a simple `StrBuf` for an error. You'd probably want a struct:

    pub struct LibError {
        message: StrBuf,
        error: Error
    }

    pub enum Error {
        One,
        Two,
        Three
    }

Where `Lib` is the library/project name.

You can then create a new result type based on your new error type:

    type LibResult = Result;

Then you can use `LibResult` everywhere in your app.

You can view this example done in a few of my own libraries (https://github.com/TheHydroImpulse/gossip.rs/blob/master/src...) and cargo (https://github.com/carlhuda/cargo/blob/master/src/cargo/util...).

That's a simple overview of it. Error handling is super simple, not verbose (thanks to try!) and in your control. Because of Rust's type system, things like `Result` is available and are so much better than simple return values (like integers: -1 vs 0 uhhh)

In addition to the (very handy) try! macro you can also map over Results and even chain monadic-like operations on them (either on the Ok or Err sides of a Result):

    enum FooError {
        XWasFalse,
        XWasUnknown
    }

    enum BarError {
        VectorTooLarge,
        FooErr(FooError)
    }

    fn foo(x: Option) -> Result {
        match x {
            Some(true) => Ok(42),
            Some(false) => Err(XWasFalse),
            _ => Err(XWasUnknown)
        }
    }

    fn bar() -> Result, BarError> {
        foo(None).or_else(|e| {
            // We can recover from an XWasUnknown error returned by
            // Foo, but not from a XWasFalse, so we return the error wrapped
            // in bar's error type.
            match e {
                XWasFalse => Err(FooErr(e)),
                XWasUnknown => Ok(99)
            }
        }).and_then(|n| {
            if n  = Vec::with_capacity(n);
                Ok(vec)
            } else {
                Err(VectorTooLarge)
            }
        }).map(|vec| {
            vec.iter().map(|_| { 42 }).collect()
        })
    }

edit: added a better example