Rust for C++ Programmers Part 7: Data Types

http://featherweightmusings.blogspot.com/2014/05/rust-for-c-programmers-part-7-data-types.html

by ihnorton • 12 years ago

93 38 12 years ago

featherweightmusings.blogspot.com

ihnorton• 12 years ago

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.

stormbrew2• 12 years ago

For some reason I have an instinctual reaction that you should have to specify the type, but on reflection I'm not sure why. It is completely redundant, and since the fields aren't named for the purposes of a destructuring assignment like this any 2-field tuple is essentially equivalent.

Hm.

kibwen6• 12 years ago

Tuple structs aren't used often, but the whole point of them is to force you to name a type. The idea is to restrict the types that you can call a function with; it turns a given tuple from a structural type to a nominal type.

For example, say you have two functions, where each function takes a single tuple of two floating point numbers:

  // Converts a Cartesian coordinate to a polar coordinate
  fn to_polar(coord: (f64, f64)) -> (f64, f64) { ... }

  // Calculates the area of a rectangle
  fn area(rect: (f64, f64)) -> f64 { ... }

Now, if you have a tuple that represents a coordinate, perhaps you don't want to feed it to the `area` function. Likewise for feeding a rectangle to the `to_polar` function. But because tuples are just structural types, something like `area(to_polar((2.5, 3.7))` is completely legal.

If you didn't want to allow this, or even if you just wanted to have greater control over all these anonymous tuples floating around, you'd use tuple structs to give them names:

  struct CarteCoord(f64, f64);
  struct PolarCoord(f64, f64);
  struct Rectangle(f64, f64);
  struct Area(f64);  // bonus round!

  fn to_polar(coord: CarteCoord) -> PolarCoord { ... }
  fn area(rect: Rectangle) -> Area { ... }

Taking the above steps makes `area(to_polar(CarteCoord(2.5, 3.7)))` a compile-time error. It's all about how strict you want to be with your types.

nrc2• 12 years ago

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).

kibwen6• 12 years ago

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
  }

kzrdude2• 12 years ago

What they mean is that there would be special cases for let patterns so that

     let (a, b) = Foo(a,b);

is a fine destructuring. It would be a special case for let, since the pattern would have to be more explicit in function arguments and in match, but I think they have a good point.

Nycto• 12 years ago

I would love to see an article like this for error handling in Rust. I was really interested in using conditions, but those were apparently backed out. Which leaves error handling through return values and macros. This seems like a step back from Exceptions to me. I want to be convinced otherwise, but I'm struggling to see how this is better than other mechanisms.

TheHydroImpulse• 12 years ago

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

    fn can_fail(arg: bool) -> Result<(), StrBuf> {
        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<(), StrBuf> {
         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<T> = Result<T, LibError>;

Then you can use `LibResult<T>` 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<T, E>` is available and are so much better than simple return values (like integers: -1 vs 0 uhhh)

tomjakubowski• 12 years ago

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<bool>) -> Result<uint, FooError> {
        match x {
            Some(true) => Ok(42),
            Some(false) => Err(XWasFalse),
            _ => Err(XWasUnknown)
        }
    }

    fn bar() -> Result<Vec<uint>, 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 < 100 {
                let vec: Vec<()> = Vec::with_capacity(n);
                Ok(vec)
            } else {
                Err(VectorTooLarge)
            }
        }).map(|vec| {
            vec.iter().map(|_| { 42 }).collect()
        })
    }

edit: added a better example

doe88• 12 years ago

Another really great thing about returning a result Result<T, E> is that your caller code will then must use this return value or otherwise a warning will be emitted by the compiler at compile time. For those interested, more details are provided in the core lib documentation: http://doc.rust-lang.org/core/result/

Pxtl2• 12 years ago

I tend to practice "only catch what you can handle" in exception-enabled languages - I haven't written in a systems language in almost a decade, mostly bad memories of C. How much does error-handling get in the way when you have to live without stack unwinding?

proksoup• 12 years ago

Is it maybe explicit programming? In my own mind I don't understand why errors should receive special treatment in the language. I prefer to explicitly handle them always.

kibwen6• 12 years ago

  > This seems like a step back from Exceptions to me. I 
  > want to be convinced otherwise, but I'm struggling to 
  > see how this is better than other mechanisms.

In a low-level language, guaranteeing memory safety in the face of resumable exceptions would be a nightmare. See Graydon's original post on the choice to avoid exceptions:

https://mail.mozilla.org/pipermail/rust-dev/2013-April/00381...

Selected quote:

  > In particular, to summarize for the impatient: once you get resumable 
  > exceptions, your code can only be correct if it leaves every data 
  > structure that might persist through an unwind-and-catch (that it 
  > acquired through &mut or @mut or the like, and live in an outer frame) 
  > in an internally-consistent state, at every possible exception-point.

  > I.e. you have to write in transactional/atomic-writes style in order to 
  > be correct. This is both performance-punitive and very hard to get 
  > right. Most C++ code simply isn't correct in this sense. Convince 
  > yourself via a quick read through the GotWs strcat linked to:

  > http://www.gotw.ca/gotw/059.htm
  > http://www.gotw.ca/gotw/008.htm

For more on the topic of exception-safety in C++, see the following paper by Bjarne Stroustrup:

http://www.stroustrup.com/except.pdf

I don't think that Rust's error handling solution is ideal, but I think that it might be approaching the best possible solution for its chosen context. Error handling is a hard problem!

kibwen6• 12 years ago

One last thing that deserves to be mentioned: Rust does have unwinding-on-failure, which is similar to exceptions, with the restriction that unwinding can only be caught at task boundaries. This allows failure in a single component to be isolated and contained. The pertinent distinction here is that the unwinding is not resumable in the normal sense; at best, a parent task can detect that a child task has failed and attempt to restart the task, without having the ability to persist any of the failed task's state.

shasta• 12 years ago

resumable exceptions

The word resumable is important to that quote, which isn't arguing against exceptions in general.

winter_blue• 12 years ago

I just read the first section, just the section on structs -- what's different here, from C? It provides all of the same features, with a slightly different syntax.

nrc2• 12 years ago

With structs, pretty much the only difference is the syntax. Enums are probably where the biggest differences are from C, as far as data types go.

kzrdude2• 12 years ago

Read the rest!

To start you off, the best and most major difference to C is that Rust structs can have destructors.

Rust for C++ Programmers Part 7: Data Types

Related Stories