• Feature Name: try_trait
• Start Date: 2017-01-19
• RFC PR: rust-lang/rfcs#1859
• Rust Issue: rust-lang/rust#31436

Summary

Introduce

Motivation

Using ? with types other than Result

結果、戻り値

The ? operator

#![allow(unused)]
fn main() {
let lhs_budget = try_opt!(width.checked_sub(prefix.len() + infix.len()));
let rhs_budget = try_opt!(width.checked_sub(suffix.len()));
}

The overarching goal of this RFC is to allow

#![allow(unused)]
fn main() {
let lhs_budget = width.checked_sub(prefix.len() + infix.len())?;
let rhs_budget = width.checked_sub(suffix.len())?;
}

Naturally, this has all the advantages that ? offered over try! to begin with:

• suffix notation,
  記法
  allowing
  許可する、可能にする
  for more fluent APIs;
• concise, yet noticeable.

However, there are some tensions to be resolved. We don't want to hardcode the behavior

• a successful result;
  結果、戻り値
• a "not ready yet" value, indicating that the caller
  呼び出し側
  should try again later;
• an error.

Code working with futures typically

#![allow(unused)]
fn main() {
enum Poll<T, E> {
    Ready(T),
    NotReady,
    Error(E),
}
}

Then one could replace code like try_ready!(self.stream.poll()) with self.stream.poll()?.

(Currently, the type Poll in the futures crate is defined

Support interconversion, but with caution

The existing try! macro and ? operator

In some cases, it would be useful to be able to convert

#![allow(unused)]
fn main() {
fn foo() -> Poll<T, E> {
    let x = bar()?; // propagate error case
}
}

and we might wish to do the same, but in a function returning a Result

#![allow(unused)]
fn main() {
fn foo() -> Result<T, E> {
    let x = bar()?; // propagate error case
}
}

However, we wish to be sure that this sort of interconversion is intentional. In particular, Result

Detailed design

設計（する）

Playground

Note: if you wish to experiment, this Rust playgroud link contains

Desugaring and the Try trait

The desugaring of the ? operator

#![allow(unused)]
fn main() {
match Try::into_result(expr) {
    Ok(v) => v,

    // here, the `return` presumes that there is
    // no `catch` in scope:
    Err(e) => return Try::from_error(From::from(e)),
}
}

If a catch is in scope, the desugaring is roughly the same, except that instead of returning, we would break out of the catch with e as the error value.

This definition

#![allow(unused)]
fn main() {
trait Try {
    type Ok;
    type Error;
    
    /// Applies the "?" operator. A return of `Ok(t)` means that the
    /// execution should continue normally, and the result of `?` is the
    /// value `t`. A return of `Err(e)` means that execution should branch
    /// to the innermost enclosing `catch`, or return from the function.
    ///
    /// If an `Err(e)` result is returned, the value `e` will be "wrapped"
    /// in the return type of the enclosing scope (which must itself implement
    /// `Try`). Specifically, the value `X::from_error(From::from(e))`
    /// is returned, where `X` is the return type of the enclosing function.
    fn into_result(self) -> Result<Self::Ok, Self::Error>;

    /// Wrap an error value to construct the composite result. For example,
    /// `Result::Err(x)` and `Result::from_error(x)` are equivalent.
    fn from_error(v: Self::Error) -> Self;

    /// Wrap an OK value to construct the composite result. For example,
    /// `Result::Ok(x)` and `Result::from_ok(x)` are equivalent.
    ///
    /// *The following function has an anticipated use, but is not used
    /// in this RFC. It is included because we would not want to stabilize
    /// the trait without including it.*
    fn from_ok(v: Self::Ok) -> Self;
}
}

Initial

初期

impls

libcore will also define

Result

The Result

#![allow(unused)]
fn main() {
impl<T,E> Try for Result<T, E> {
    type Ok = T;
    type Error = E;

    fn into_result(self) -> Self {
        self
    }
    
    fn from_ok(v: T) -> Self {
        Ok(v)
    }

    fn from_error(v: E) -> Self {
        Err(v)
    }
}
}

This impl permits

Option

The Option type includes an impl as follows:

#![allow(unused)]
fn main() {
mod option {
    pub struct Missing;

    impl<T> Try for Option<T>  {
        type Ok = T;
        type Error = Missing;

        fn into_result(self) -> Result<T, Missing> {
            self.ok_or(Missing)
        }
    
        fn from_ok(v: T) -> Self {
            Some(v)
        }

        fn from_error(_: Missing) -> Self {
            None
        }
    }
}    
}

Note the use of the Missing type, which is specific

The use of a fresh type like Missing is recommended whenever one implements

Interaction with type inference

Supporting more types with the ? operator

This implies that callers

#![allow(unused)]
fn main() {
vec.iter().map(|e| ...).collect::<Result<_, _>>()?
}

Another problem (which also occurs

How We Teach This

Where and how to document

文書

it

This RFC proposes extending

The reference

One important note is that we should publish guidelines explaining when it is appropriate to introduce

Error messages

Another important factor is the error message when ? is used in a function whose return type is not suitable. The current error message in this scenario is quite opaque and directly

Source

? cannot be applied

適用する

to a value of type Foo

Return type does not implement

cannot use the ? operator

演算子

in a function that returns ()

or perhaps if we want to be more strictly correct:

? cannot be applied

適用する

to a Result<T, Box<Error>> in a function that returns ()

At this point, we could likely make a suggestion such as "consider

Note however that if ? is used within an impl of a trait method, or within main(), or in some other context

Errors cannot be interconverted. Finally, if the return type R does implement

? cannot be applied

適用する

to a Result<T, Box<Error>> in a function that returns Option<T>

This last part can be tricky, because the error can result

• a missing From impl, perhaps a mistake;
• the impl of Try is intentionally limited, as in the case of Option.

We could help the user diagnose this, most likely, by offering some labels like the following:

#![allow(unused)]
fn main() {
22 | fn foo(...) -> Option<T> {
   |                --------- requires an error of type `option::Missing`
   |     write!(foo, ...)?;
   |     ^^^^^^^^^^^^^^^^^ produces an error of type `io::Error`
   | }
}

Consider

Extended

fn inner_main() -> Result<(), HLError> {
    let args = parse_cmdline()?;
    // all the real work here
}

fn main() {
    process::exit(match inner_main() {
        Ok(_) => 0,
        Err(ref e) => {
            writeln!(io::stderr(), "{}", e).unwrap();
            1
        }
    });
}

Implementation

Drawbacks

One drawback of supporting more types is that type inference becomes harder. This is because an expression

There is also the risk that results

Alternatives

The "essentialist" approach

When this RFC was first proposed, the Try trait looked quite different:

#![allow(unused)]
fn main() {
trait Try<E> {
    type Success;
    fn try(self) -> Result<Self::Success, E>;
}    
}

In this version, Try::try() converted

This was changed to adopt the current "reductionist" approach, in which all values are first interconverted (in a context

• The resulting
  結果、戻り値
  trait feels simpler and more straight-forward. It also supports from_ok in a simple fashion.
• Context
  文脈、背景
  dependent behavior
  ふるまい
  has the potential to be quite surprising.
• The use of specific
  特定の
  types like option::Missing mitigates the primary
  主要な、初等の、第一の
  concern that motivated the original design
  設計（する）
  (avoiding overly loose interconversion).
• It is nice that the use of the From trait is now part of the ? desugaring, and hence supported universally across all types.
• The interaction with the orphan rules is made somewhat nicer. For example, using the essentialist alternative,
  代わりのもの、選択肢
  one might like to have a trait that permits
  許す
  a Result
  結果、戻り値
  to be returned in a function that yields
  産出する、出力する
  Poll. That would require an impl like this impl<T,E> Try<Poll<T,E>> for Result<T, E>, but this impl runs afoul of the orphan rules.

Traits implemented

実装する

over higher-kinded types

The desire to avoid

What to name the trait

A number of names have been proposed for this trait. The original name was Carrier, as the implementing type was the "carrier" for an error value. A proposed alternative

Unresolved questions

None.