• Feature Name: try_trait_v2
• Start Date: 2020-12-12
• RFC PR: rust-lang/rfcs#3058
• Rust Issue: rust-lang/rust#84277

Summary

Replace RFC #1859, try_trait, with a new design

The new design

This is forward-looking to be compatible with other features, like try {} blocks or yeet e expressions

Motivation

The motivations from the previous

• Using the "error" terminology is a poor fit for other potential implementations
  実装
  of the trait.
• The previous
  前の
  RFC's mechanism
  仕組み、機構
  for controlling
  制御する
  interconversions proved ineffective, with inference meaning that people did it unintentionally.
• It's no longer clear that From should be part of the ? desugaring for all types. It's both more flexible -- making inference difficult -- and more restrictive -- especially without specialization -- than is always desired.
• An experience report in the tracking issue mentioned that it's annoying to need to make a residual type in common cases.

This RFC proposes a solution that mixes the two major options considered

• Like the reductionist approach, this RFC proposes an unparameterized trait with an associated type for the "ok" part, so that the type produced
  産出、産出する
  from the ? operator
  演算子
  on a value is always the same.
• Like the essentialist approach, this RFC proposes a trait with a generic parameter
  仮引数
  for "error" part, so that different types can be consumed.

Guide-level explanation

The ops::ControlFlow type

This is a simple enum:

#![allow(unused)]
fn main() {
enum ControlFlow<B, C = ()> {
    /// Exit the operation without running subsequent phases.
    Break(B),
    /// Move on to the next phase of the operation as normal.
    Continue(C),
}
}

It's intended for exposing things (like graph traversals or visitor) where you want the user to be able to choose whether to exit early. Using an enum is clearer than just using a bool -- what did false mean again? -- as well as allows

For example, you could use it to expose a simple tree traversal in a way that lets the caller

#![allow(unused)]
fn main() {
impl<T> TreeNode<T> {
    fn traverse_inorder<B>(&self, mut f: impl FnMut(&T) -> ControlFlow<B>) -> ControlFlow<B> {
        if let Some(left) = &self.left {
            left.traverse_inorder(&mut f)?;
        }
        f(&self.value)?;
        if let Some(right) = &self.right {
            right.traverse_inorder(&mut f)?;
        }
        ControlFlow::Continue(())
    }
}
}

Now, you could write the same thing with Result<(), B> instead. But that would require that the passed-in closure use Err(value) to early-exit the traversal, which can cause

The Try trait

The ops::Try trait describes

At its core, the ? operator

• The output that will be returned from the ? expression,
  式
  with which the program will continue, and
• The residual that will be returned to the calling
  呼び出し
  code, as an early exit from the normal flow.

(Oxford's definition

The Try trait also has facilities

Here's a quick overview of a few standard types which implement

+-------------+                             +-------------------+                          +-------------------+
| Try::Output |                             |      Try Type     |                          |   Try::Residual   |
+-------------+   Try::branch is Continue   +-------------------+   Try::branch is Break   +-------------------+
|      T      |  <------------------------  |   Result<T, E>    |  --------------------->  |   Result<!, E>    |
|      T      |                             |     Option<T>     |                          |     Option<!>     |
|      C      |  ------------------------>  | ControlFlow<B, C> |  <---------------------  | ControlFlow<B, !> |
+-------------+      Try::from_output       +-------------------+    Try::from_residual    +-------------------+

If you've used ?-on-Result

The residual types, however, are somewhat more interesting. Code using ? doesn't see them directly

Most importantly, this gives each family of types (Result

🏗️ Note for those familiar with the previous

前の

RFC 🏗️

This is the most critical semantic difference. Structurally this definition

定義

of the trait is very similar

似ている、同様の

to the previous

前の

-- there's still a method splitting the type into a discriminated union between two associated types, and constructors

function Object() { [native code] }

to rebuild it from them. But by keeping the "result-ness" or "option-ness" in the residual type, it gives extra control

制御する

over interconversion that wasn't possible before. The changes other than this are comparatively minor, typically

一般的に、典型的に

either rearrangements to work with that or renamings to change the vocabulary used in the trait.

Using ! is then just a convenient yet efficient

How error conversion

変換

works

One thing The Book mentions, if you recall, is that error values in ? have From::from called

The previous

#![allow(unused)]
fn main() {
trait FromResidual<Residual = <Self as Try>::Residual> {
    fn from_residual(r: Residual) -> Self;
}
}

And while we're showing code, here's the exact definition

#![allow(unused)]
fn main() {
trait Try: FromResidual {
    type Output;
    type Residual;
    fn branch(self) -> ControlFlow<Self::Residual, Self::Output>;
    fn from_output(o: Self::Output) -> Self;
}
}

The fact that it's a super-trait like that is why I don't feel bad about the slight lie: Every T: Try always has a from_residual function from T::Residual to T. It's just that some types might offer more.

Here's how Result

#![allow(unused)]
fn main() {
impl<T, E, F: From<E>> FromResidual<Result<!, E>> for Result<T, F> {
    fn from_residual(x: Result<!, E>) -> Self {
        match x {
            Err(e) => Err(From::from(e)),
        }
    }
}
}

But Option doesn't need to do anything exciting, so just has a simple implementation,

#![allow(unused)]
fn main() {
impl<T> FromResidual for Option<T> {
    fn from_residual(x: Self::Residual) -> Self {
        match x {
            None => None,
        }
    }
}
}

In your own types, it's up to you to decide how much freedom is appropriate. You can even enable interconversion by defining

🏗️ Note for those familiar with the previous

前の

RFC 🏗️

This is another notable difference: The From::from is up to the trait implementation,

実装

not part of the desugaring.

Implementing

実装する

Try for a non-generic type

The examples in the standard library are all generic, so serve

Suppose we're working on migrating some C code to Rust, and it's still using the common "zero is success; non-zero is an error" pattern. Maybe we're using a simple type like this to stay ABI-compatible:

#![allow(unused)]
fn main() {
#[derive(Debug, Copy, Clone, Eq, PartialEq)]
#[repr(transparent)]
pub struct ResultCode(pub i32);
impl ResultCode {
    const SUCCESS: Self = ResultCode(0);
}
}

We can implement

First, we'll need a residual type. We can make this a simple newtype, and conveniently there's a type with a niche for exactly

#![allow(unused)]
fn main() {
use std::num::NonZeroI32;
pub struct ResultCodeResidual(NonZeroI32);
}

With that, it's straight-forward to implement

#![allow(unused)]
fn main() {
impl Try for ResultCode {
    type Output = ();
    type Residual = ResultCodeResidual;
    fn branch(self) -> ControlFlow<Self::Residual> {
        match NonZeroI32::new(self.0) {
            Some(r) => ControlFlow::Break(ResultCodeResidual(r)),
            None => ControlFlow::Continue(()),
        }
    }
    fn from_output((): ()) -> Self {
        ResultCode::SUCCESS
    }
}

impl FromResidual for ResultCode {
    fn from_residual(r: ResultCodeResidual) -> Self {
        ResultCode(r.0.into())
    }
}
}

Aside: As a nice bonus, the use of a NonZero type in the residual means that <ResultCode as Try>::branch compiles down to a nop on the current nightly. Thanks, enum layout optimizations!

Now, this is all great for keeping the interface that the other unmigrated C code expects, and can even work in no_std if we want. But it might also be nice to give other Rust code that uses it the option to convert

For expository purposes, we'll use this error type:

#![allow(unused)]
fn main() {
#[derive(Debug, Clone)]
pub struct FancyError(String);
}

(A real one would probably be more complicated and have a better name, but this will work for what we need here -- it's bigger and needs non-core things to work.)

We can allow

#![allow(unused)]
fn main() {
impl<T, E: From<FancyError>> FromResidual<ResultCodeResidual> for Result<T, E> {
    fn from_residual(r: ResultCodeResidual) -> Self {
        Err(FancyError(format!("Something fancy about {} at {:?}", r.0, std::time::SystemTime::now())).into())
    }
}
}

The split between different error strategies in this section

Using these traits in generic code

Iterator::try_fold has been stable to call

As a reminder, an infallible version of a fold looks something like this:

#![allow(unused)]
fn main() {
fn simple_fold<A, T>(
    iter: impl Iterator<Item = T>,
    mut accum: A,
    mut f: impl FnMut(A, T) -> A,
) -> A {
    for x in iter {
        accum = f(accum, x);
    }
    accum
}
}

So instead of f returning just an A, we'll need it to return some other type that produces

Let's add a new generic parameter

#![allow(unused)]
fn main() {
fn simple_try_fold_1<A, T, R: Try<Output = A>>(
    iter: impl Iterator<Item = T>,
    mut accum: A,
    mut f: impl FnMut(A, T) -> R,
) -> R {
    todo!()
}
}

Try is also the trait we need to get the updated accumulator from f's return value and return the result

#![allow(unused)]
fn main() {
fn simple_try_fold_2<A, T, R: Try<Output = A>>(
    iter: impl Iterator<Item = T>,
    mut accum: A,
    mut f: impl FnMut(A, T) -> R,
) -> R {
    for x in iter {
        let cf = f(accum, x).branch();
        match cf {
            ControlFlow::Continue(a) => accum = a,
            ControlFlow::Break(_) => todo!(),
        }
    }
    R::from_output(accum)
}
}

We'll also need FromResidual::from_residual to turn the residual back into the original type. But because it's a supertrait of Try, we don't need to mention it in the bounds.

#![allow(unused)]
fn main() {
pub fn simple_try_fold_3<A, T, R: Try<Output = A>>(
    iter: impl Iterator<Item = T>,
    mut accum: A,
    mut f: impl FnMut(A, T) -> R,
) -> R {
    for x in iter {
        let cf = f(accum, x).branch();
        match cf {
            ControlFlow::Continue(a) => accum = a,
            ControlFlow::Break(r) => return R::from_residual(r),
        }
    }
    R::from_output(accum)
}
}

But this "call

#![allow(unused)]
fn main() {
fn simple_try_fold<A, T, R: Try<Output = A>>(
    iter: impl Iterator<Item = T>,
    mut accum: A,
    mut f: impl FnMut(A, T) -> R,
) -> R {
    for x in iter {
        accum = f(accum, x)?;
    }
    R::from_output(accum)
}
}

Reference-level explanation

ops::ControlFlow

#![allow(unused)]
fn main() {
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum ControlFlow<B, C = ()> {
    /// Exit the operation without running subsequent phases.
    Break(B),
    /// Move on to the next phase of the operation as normal.
    Continue(C),
}
}

The traits

#![allow(unused)]
fn main() {
pub trait Try: FromResidual {
    /// The type of the value consumed or produced when not short-circuiting.
    type Output;

    /// A type that "colours" the short-circuit value so it can stay associated
    /// with the type constructor from which it came.
    type Residual;

    /// Used in `try{}` blocks to wrap the result of the block.
    fn from_output(x: Self::Output) -> Self;

    /// Determine whether to short-circuit (by returning `ControlFlow::Break`)
    /// or continue executing (by returning `ControlFlow::Continue`).
    fn branch(self) -> ControlFlow<Self::Residual, Self::Output>;
}

pub trait FromResidual<Residual = <Self as Try>::Residual> {
    /// Recreate the type implementing `Try` from a related residual
    fn from_residual(x: Residual) -> Self;
}
}

Expected laws

What comes out is what you put in:

• <T as Try>::from_output(x).branch() ⇒ ControlFlow::Continue(x) (aka try { x }? ⇒ x)
• <T as Try>::from_residual(x).branch() ⇒ ControlFlow::Break(x) (maybe aka something like try { yeet e } ⇒ Err(e), see the future possibilities)

You can recreate what you split up:

• match
  一致する、マッチさせる
  x.branch() { ControlFlow::Break(r) => Try::from_residual(r), ControlFlow::Continue(v) => Try::from_output(v) } ⇒ x (aka try { x? } ⇒ x)

Desugaring ?

The previous

#![allow(unused)]
fn main() {
match Try::into_result(x) {
    Ok(v) => v,
    Err(e) => return Try::from_error(From::from(e)),
}
}

The new one is very similar:

#![allow(unused)]
fn main() {
match Try::branch(x) {
    ControlFlow::Continue(v) => v,
    ControlFlow::Break(r) => return FromResidual::from_residual(r),
}
}

The critical difference is that conversion

Standard implementations

実装

Result

結果、戻り値

#![allow(unused)]
fn main() {
impl<T, E> ops::Try for Result<T, E> {
    type Output = T;
    type Residual = Result<!, E>;

    #[inline]
    fn from_output(c: T) -> Self {
        Ok(c)
    }

    #[inline]
    fn branch(self) -> ControlFlow<Self::Residual, T> {
        match self {
            Ok(c) => ControlFlow::Continue(c),
            Err(e) => ControlFlow::Break(Err(e)),
        }
    }
}

impl<T, E, F: From<E>> ops::FromResidual<Result<!, E>> for Result<T, F> {
    fn from_residual(x: Result<!, E>) -> Self {
        match x {
            Err(e) => Err(From::from(e)),
        }
    }
}
}

Option

#![allow(unused)]
fn main() {
impl<T> ops::Try for Option<T> {
    type Output = T;
    type Residual = Option<!>;

    #[inline]
    fn from_output(c: T) -> Self {
        Some(c)
    }

    #[inline]
    fn branch(self) -> ControlFlow<Self::Residual, T> {
        match self {
            Some(c) => ControlFlow::Continue(c),
            None => ControlFlow::Break(None),
        }
    }
}

impl<T> ops::FromResidual for Option<T> {
    fn from_residual(x: <Self as ops::Try>::Residual) -> Self {
        match x {
            None => None,
        }
    }
}
}

Poll

These reuse Result

#![allow(unused)]
fn main() {
impl<T, E> ops::Try for Poll<Result<T, E>> {
    type Output = Poll<T>;
    type Residual = <Result<T, E> as ops::Try>::Residual;

    fn from_output(c: Self::Output) -> Self {
        c.map(Ok)
    }

    fn branch(self) -> ControlFlow<Self::Residual, Self::Output> {
        match self {
            Poll::Ready(Ok(x)) => ControlFlow::Continue(Poll::Ready(x)),
            Poll::Ready(Err(e)) => ControlFlow::Break(Err(e)),
            Poll::Pending => ControlFlow::Continue(Poll::Pending),
        }
    }
}

impl<T, E, F: From<E>> ops::FromResidual<Result<!, E>> for Poll<Result<T, F>> {
    fn from_residual(x: Result<!, E>) -> Self {
        match x {
            Err(e) => Poll::Ready(Err(From::from(e))),
        }
    }
}
}

#![allow(unused)]
fn main() {
impl<T, E> ops::Try for Poll<Option<Result<T, E>>> {
    type Output = Poll<Option<T>>;
    type Residual = <Result<T, E> as ops::Try>::Residual;

    fn from_output(c: Self::Output) -> Self {
        c.map(|x| x.map(Ok))
    }

    fn branch(self) -> ControlFlow<Self::Residual, Self::Output> {
        match self {
            Poll::Ready(Some(Ok(x))) => ControlFlow::Continue(Poll::Ready(Some(x))),
            Poll::Ready(Some(Err(e))) => ControlFlow::Break(Err(e)),
            Poll::Ready(None) => ControlFlow::Continue(Poll::Ready(None)),
            Poll::Pending => ControlFlow::Continue(Poll::Pending),
        }
    }
}

impl<T, E, F: From<E>> ops::FromResidual<Result<!, E>> for Poll<Option<Result<T, F>>> {
    fn from_residual(x: Result<!, E>) -> Self {
        match x {
            Err(e) => Poll::Ready(Some(Err(From::from(e)))),
        }
    }
}
}

ControlFlow

#![allow(unused)]
fn main() {
impl<B, C> ops::Try for ControlFlow<B, C> {
    type Output = C;
    type Residual = ControlFlow<B, !>;

    fn from_output(c: C) -> Self {
        ControlFlow::Continue(c)
    }

    fn branch(self) -> ControlFlow<Self::Residual, C> {
        match self {
            ControlFlow::Continue(c) => ControlFlow::Continue(c),
            ControlFlow::Break(b) => ControlFlow::Break(ControlFlow::Break(b)),
        }
    }
}

impl<B, C> ops::FromResidual for ControlFlow<B, C> {
    fn from_residual(x: <Self as ops::Try>::Residual) -> Self {
        match x {
            ControlFlow::Break(r) => ControlFlow::Break(r),
        }
    }
}
}

Use in Iterator

The provided

#![allow(unused)]
fn main() {
fn try_fold<B, F, R>(&mut self, init: B, mut f: F) -> R
where
    Self: Sized,
    F: FnMut(B, Self::Item) -> R,
    R: Try<Output = B>,
{
    let mut accum = init;
    while let Some(x) = self.next() {
        accum = f(accum, x)?;
    }
    try { accum }
}
}

Drawbacks

• While this handles a known accidental stabilization, it's possible that there's something else unknown that will keep this from being doable while meeting Rust's stringent stability guarantees.
  保証する
• The extra complexity of this approach, compared
  比較する
  to either of the alternatives
  代わりのもの、選択肢
  considered
  みなす、考慮する
  the last time around, might not be worth it.
• This is the fourth attempt at a design
  設計（する）
  in this space, so it might not be the right one either.
• As with all overloadable operators,
  演算子
  users might implement
  実装する
  this to do something weird.
• In situations where extensive interconversion is desired, this requires more implementations.
  実装
• Moving From::from from the desugaring to the implementations
  実装
  means that implementations
  実装
  which do want it are more complicated.

Rationale and alternatives

代わりのもの、選択肢

Why ControlFlow pulls its weight

The previous

This RFC does use a new type because one already exists in nightly under the control_flow_enum feature gate. It's being used in the library and the compiler, demonstrating that it's useful beyond just this desugaring, so the desugar might as well use it too for extra clarity. There are also ecosystem changes waiting on something like it, so it's not just a compiler-internal need.

Methods on ControlFlow

On nightly there are a variety of methods available on ControlFlow. However, none of them are needed for the stabilization of the traits, so they left out of this RFC. They can be considered

There's a basic set

#![allow(unused)]
fn main() {
impl<B, C> ControlFlow<B, C> {
    fn is_break(&self) -> bool;
    fn is_continue(&self) -> bool;
    fn break_value(self) -> Option<B>;
    fn continue_value(self) -> Option<C>;
}
}

Traits for ControlFlow

ControlFlow derives a variety of traits where they have obvious behaviour. It does not, however, derive

For Options, None < Some(_), but for Result

Leaving it out also leaves us free to change the ordering of the variants in the definition

Naming the variants on ControlFlow

The variants are given

For example, this (admittedly contrived) loop

#![allow(unused)]
fn main() {
let mut sum = 0;
for x in iter {
    if x % 2 == 0 { continue }
    sum += x;
    if sum > 100 { break }
    continue
}
}

can be written as

#![allow(unused)]
fn main() {
let mut sum = 0;
iter.try_for_each(|x| {
    if x % 2 == 0 { return ControlFlow::Continue(()) }
    sum += x;
    if sum > 100 { return ControlFlow::Break(()) }
    ControlFlow::Continue(())
});
}

(Of course, one wouldn't normally use the continue keyword at the end of a for loop like that, but I've included it here to emphasize that even the ControlFlow::Continue(()) as the final expression

Why ControlFlow has C = ()

The type that eventually became ControlFlow was originally added

Issue #75744 in 2020 started the process of exposing it, coming out of the observation that Iterator::try_fold isn't a great replacement for the deprecated-at-the-time Itertools::fold_while since using Err for a conceptual success makes code hard to read.

The compiler actually had its own version of the type in librustc_data_structures at the time:

#![allow(unused)]
fn main() {
pub enum ControlFlow<T> {
    Break(T),
    Continue,
}
}

The compiler was moved over to the newly-exposed type, and that inspired the creation of MCP#374, TypeVisitor: use ops::ControlFlow instead of bool. Experience from that lead to flipping the type arguments

As an additional

i didn't read your proposal in depth, but this reminds me of a recursive search function i experimented with a few days ago. It used a Result

結果、戻り値

type as output, where Err(value) meant that it found the value and Ok(()) meant that it didn't find the value. That way i could use the ? to exit early

So when thinking about ControlFlow, it's often best to think of it not like Result

Was this considered

みなす、考慮する

last time?

Interestingly, a previous

Current desires for the solution, however, have more requirements than were included in the RFC at the time of that version. Notably, the stabilized Iterator::try_fold method depends on being able to create a Try type from the accumulator. Including such a constructor

Also, ok-wrapping was decided in #70941, which needs such a constructor,

Why not make the output a generic type?

It's helpful that type information can flow both ways through ?.

• In the forward direction,
  方向
  not needing a contextual type means that println!("{}", x?) works instead of needing a type annotation. (It's also just less confusing to have ? on the same type always produce
  産出する
  the same type.)
• In the reverse direction,
  方向
  it allows
  許可する、可能にする
  things like let x: i32 = s.parse()?; to infer the requested type from that annotation, rather than requiring it be specified
  特定する、指定する、規定する
  again.

Similar

• let y: anyhow::Result<_> = try { x }; doesn't need to repeat the type of x.
• let x: i16 = { 4 }; works for infallible code, so for consistency it's good for let x: anyhow::Result<i16> = try { 4 }; to also work (rather than default the literal to i32 and fail).

Why does FromResidual take

とる

a generic type?

The simplest case is that the already-stable error conversions

However, more experience with trying to use Try for scenarios other than "the early exit is an error" have shown that forcing this on everything is inappropriate. ControlFlow, for example, would rather not have it, for the same kinds of reasons that return and break-from-loop don't implicitly

But even for the error path, forcing From causes

my mind is exploding, the possibility of all error types implementing

実装する

error the way they actually should has such massive implications for the rest of the error reporting stuff we've been working on

As a bonus, moving conversion

Why not merge Try and FromResidual?

This RFC treats

#![allow(unused)]
fn main() {
trait Try<Residual> {
    type Output;
    fn branch(self) -> ControlFlow<Residual, Self::Output>;
    fn from_residual(r: Residual) -> Self;
    fn from_output(x: Self::Output) -> Self;
}
}

This, however, is technically too much freedom. Looking at the error propagation case, it would end up calling

And even for a human, it's not clear that this freedom is helpful. While any trait can be implemented

Naming the ?-related traits and associated types

This RFC introduces the residual concept as it was helpful to have a name to talk about in the guide section.

A different scheme might be clearer for people. For example, there's some elegance to matching

As a sketch, one of those alternatives

#![allow(unused)]
fn main() {
trait Try: FromBreak {
    type Break;
    type Continue;
    fn branch(self) -> ControlFlow<Self::Break, Self::Continue>;
    fn from_continue(c: Self::Continue) -> Self;
}
trait FromBreak<B = <Self as Try>::Break> {
    fn from_break(b: B) -> Self;
}
}

However the "boring" Output name does have the advantage that one doesn't need to remember a special name, as it's the same as the other operator

ℹ Per feedback from T-libs, this is left as an unresolved question for the RFC, to be resolved in nightly.

Splitting up Try more

This RFC encourages one to think of a Try type holistically, as something that supports all three of the core operations,

That's not necessarily the way it should go. It could be different, like there's no guarantee

Notably, the this proposal has both an introduction

One unknown question here is whether this is important for any FFI scenarios. Often error APIs come in pairs (like Win32's GetLastError and SetLastError), but some libraries may only give them out without allowing

In pure rust, one could also imagine types where it might be interesting to allow

#![allow(unused)]
fn main() {
let _: IgnoreAllErrors = try {
    foo()?;
    bar()?;
    qux()?;
};
}

which works by allowing

The split currently in the proposal, though it's there for other reasons, would allow

Another downside of the flexibility is that the structure of the traits would be somewhat more complicated.

The simplest split would just move each method to its own trait,

#![allow(unused)]
fn main() {
trait Branch {
    type Output;
    type Residual;
    fn branch(self) -> ControlFlow<Self::Residual, Self::Output>;
}
trait FromOutput {
    type Output;
    fn from_output(x: Self::Output) -> Self;
}
trait FromResidual<R> {
    fn from_residual(x: R) -> Self;
}
}

but that loses the desired property

One way to fix that would be to add another trait for that associated type, perhaps something like

#![allow(unused)]
fn main() {
trait TryBase {
    type Output;
}
trait Branch: TryBase {
    type Residual;
    fn branch(self) -> ControlFlow<Self::Residual, Self::Output>;
}
trait FromOutput: TryBase {
    fn from_output(x: Self::Output) -> Self;
}
trait FromResidual<R> {
    fn from_residual(x: R) -> Self;
}

}

But this has still lost the simplicity

#![allow(unused)]
fn main() {
trait Try = Branch + FromOutput + FromResidual<<Self as Branch>::Residual>;
}

There are probably also useful intermediary designs

ℹ Per feedback from T-libs, this is left as an unresolved question for the RFC, to be resolved in nightly.

Why a "residual" type is better than an "error" type

Most importantly, for any type generic in its "output type" it's easy to produce

In those cases where a separate type is needed, it's still easier to make a residual type because they're transient and thus

Use of !

This RFC uses ! to be concise. It would work fine with convert::Infallible instead if ! has not yet stabilized, though a few more match

Why FromResidual is the supertrait

It's nicer for try_fold implementations

Default Residual on FromResidual

The default here is provided

FromResidual::from_residual vs Residual::into_try

Either of these directions

A major advantage of the FromResidual::from_residual direction

Converting

#![allow(unused)]
fn main() {
impl<R: std::fmt::Debug> FromResidual<R> for LogAndIgnoreErrors {
    fn from_residual(h: H) -> Self {
        dbg!(h);
        Self
    }
}
}

(Not that that's necessarily a good idea -- it's plausibly too generic. This RFC definitely isn't proposing it for the standard library.)

And, ignoring

Can we just remove the accidental interconversions?

This depends on how we choose to read the rules around breaking changes.

A crater run on a prototype implementation

Definitely a good change.

Thanks for spotting that, that was indeed a confusing mix

However another instance

The interesting pattern boils down to this:

#![allow(unused)]
fn main() {
.map(|v| Ok(something_returning_option(v)?))
}

That means it's using ? on an Option, but the closure ends up returning Result<_, NoneError> without needing to name the type as trait resolution discovers that it's the only possibility. It seems reasonable that this could happen accidentally while refactoring. That does mean, however, that the breakage could also be considered