title: What's the benefit of using a Result?
body: <p>I don't understand why <code>Result</code> exists in Rust. I can see how <code>Option</code> can be useful, but using <code>Result</code> just seems to complicate code unnecessarily. </p>
  
  <p>Consider the following example:</p>
  
  <pre><code>#[derive(PartialEq, Eq, Debug)]
  enum MyErr {
      None,
      FailOne,
  }
  
  fn returns_tuple() -&gt; (u8, MyErr) {
      // (1, None) // &lt;-- Success path
      (0, MyErr::FailOne)
  }
  
  fn returns_result() -&gt; Result&lt;u8, MyErr&gt; {
      // Ok(1) // &lt;-- Success path
      Err(MyErr::FailOne)
  }
  
  #[test]
  fn test_check_return_values() {
      let x = returns_result();
      if x.is_ok() {
          println!("result: Is OK: {}", x.unwrap()); // &lt;-- Must use unwrap
      } else {
          match x.err().unwrap() { // &lt;-- Again, unwrapping
              MyErr::None =&gt; {}, // Required for match
              MyErr::FailOne =&gt; println!("result: Failed One"),
          }
      }
  }
  
  #[test]
  fn test_check_return_values_2() {
      let (y, err) = returns_tuple();
      match err {
          MyErr::None =&gt; println!("tuple: Is OK: {}", y),
          MyErr::FailOne =&gt; println!("tuple: Failed one"),
      }
  }
  </code></pre>
  
  <p>The only thing I can see is that it minorly increases the convenience of function writers, as you can simply call <code>Ok()</code> and <code>Err()</code> to return results.</p>
  
  <p>I've seen some people saying its so you can use conditions, but that's not true at all; you can use conditions perfectly well using tuples. (<em>Note — "conditions" were a feature of Rust that were removed before 1.0</em>)</p>
  
  <p>I've also seen some people saying that <code>Result</code> is more performant that returning a tuple, but <code>Result</code> <em>is</em> a tuple, so I don't see how this can be the case.</p>