Tracking issue for `ops::Try` (`try_trait` feature)

[scottmcm]

Feature gate: #![feature(try_trait)]

This is a tracking issue for the Try trait from rust-lang/rfcs#1859.

Split off from #31436 for clarity (per #42275 (comment))

Public API

pub mod core {
    pub mod result {
        impl<T, E> ops::Try for Result<T, E> {
            type Ok = T;
            type Error = E;
            fn into_result(self) -> Self {}
            fn from_ok(v: T) -> Self {}
            fn from_error(v: E) -> Self {}
        }
    }

    pub mod option {
        #[derive(Clone, Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
        pub struct NoneError;

        impl<T> ops::Try for Option<T> {
            type Ok = T;
            type Error = NoneError;
            fn into_result(self) -> Result<T, NoneError> {}
            fn from_ok(v: T) -> Self {}
            fn from_error(_: NoneError) -> Self {}
        }
    }

    pub mod ops {
        mod r#try {
            pub trait Try {
                type Ok;
                type Error;
                fn into_result(self) -> Result<Self::Ok, Self::Error>;
                fn from_error(v: Self::Error) -> Self;
                fn from_ok(v: Self::Ok) -> Self;
            }
        }

        pub use self::r#try::Try;
    }
}

Steps / History

• Stabilizing this will allow people to implement Iterator::try_fold

  • As part of stabilizing, re-open PR Document implementing try_fold for iterators for internal iteration #62606 to document implementing try_fold for iterators
  • Ensure that the default implementations of other things have the desired long-term DAG, since changing them is essentially impossible later. (Specifically, it would be nice to have fold be implemented in terms of try_fold, so that both don't need to be overridden.)
  • Moved these to the try_trait_v2 tracking issue

• Lower ? to Try instead of Carrier #42275

• Deprecate and remove these in favour of the new versions.

Unresolved Questions

These resulted in a new rust-lang/rfcs#3058, tracked in #84277

• Open design questions around the shape of the Try trait
  • TryContinue API: Tracking issue for ops::Try (try_trait feature) #42327 (comment) and Tracking issue for ops::Try (try_trait feature) #42327 (comment)
  • Support trace capturing: Tracking issue for ops::Try (try_trait feature) #42327 (comment)
• Usability concerns with the current trait
  • Tracking issue for ops::Try (try_trait feature) #42327 (comment)
  • Tracking issue for ops::Try (try_trait feature) #42327 (comment)

[glaebhoerl]

A couple of pieces of bikeshedding:

• Do we have a particular motivation to call the associated type Error instead of Err? Calling it Err would make it line up with Result: the other one is already called Ok.

• Do we have a particular motivation for having separate from_error and from_ok methods, instead of a single from_result which would be more symmetric with into_result which is the other half of the trait?

(updated version of playground link from the RFC)

[scottmcm]

@glaebhoerl

• Error vs Err was discussed related to TryFrom in Tracking issue for TryFrom/TryInto traits #33417 (comment) and Rename TryFrom's associated type and implement str::parse using TryFrom. #40281; I assume the name was chosen here for similar reasons.
• I believe they're separate because they have different uses, and I expect it to be rare that someone actually has a Result that they're trying to turn into a T:Try. I prefer Try::from_ok and Try::from_error to always calling Try::from_result(Ok( and Try::from_result(Err(, and I'm happy to just impl the two methods over writing out the match. Perhaps that's because I think of into_result not as Into<Result>, but as "was it pass or fail?", with the specific type being Result as an unimportant implementation detail. (I don't want to suggest or reopen the "there should be a new type for produce-value vs early-return, though.) And for documentation, I like that from_error talks about ? (or eventually throw), while from_ok talks about success-wrapping (catch blocks are not Ok-wrapping their value #41414), rather than having them both in the same method.

[fluffysquirrels]

I'm not sure if this is the correct forum for this comment, please redirect me if it's not 😃. Perhaps this should have been on rust-lang/rfcs#1859 and I missed the comment period; oops!

---

I was wondering if there is a case for splitting up the Try trait or removing the into_result method; to me currently Try is somewhat like the sum of traits FromResult (containing from_error and from_ok) and IntoResult (containing into_result).

FromResult enables highly ergonomic early exit with the ? operator, which I think is the killer use case for the feature. I think IntoResult can already be implemented neatly with per-use-case methods or as Into<Result>; am I missing some useful examples?

Following the Try trait RFC, expr? could desugar as:

match expr { // Removed `Try::into_result()` here.
    Ok(v) => v,
    Err(e) => return Try::from_error(From::from(e)),
}

The motivating examples I considered are Future and Option.

Future

We can implement FromResult naturally for struct FutureResult: Future as:

impl<T, E> FromResult for FutureResult {
    type Ok = T;
    type Error = E;
    fn from_error(v: Self::Error) -> Self {
        future::err(v)
    }
    fn from_ok(v: Self::Ok) -> Self {
        future::ok(v)
    }
}

Assuming a reasonable implementation for ? that will return from an impl Future valued function when applied to a Result::Err then I can write:

fn async_stuff() -> impl Future<V, E> {
    let t = fetch_t();
    t.and_then(|t_val| {
        let u: Result<U, E> = calc(t_val);
        async_2(u?)
    })
}
fn fetch_t() -> impl Future<T, E> {}
fn calc(t: T) -> Result<U,E> {}

That is exactly what I was trying to implement earlier today and Try nails it! But if we tried to implement the current Try for Future there is perhaps no canonical choice for into_result; it could be useful to panic, block, or poll once, but none of these seems universally useful. If there were no into_result on Try I can implement early exit as above, and if I need to convert a Future to a Result (and thence to any Try) I can convert it with a suitable method (call the wait method to block, call some poll_once() -> Result<T,E>, etc.).

Option

Option is a similar case. We implement from_ok, from_err naturally as in the Try trait RFC, and could convert Option<T> to Result<T, Missing> simply with o.ok_or(Missing) or a convenience method ok_or_missing.

---

Hope that helps!

[skade]

I'm maybe very late to all this, but it occured to me this weekend that ? has a rather natural semantic in cases where you'd like to short-circuit on success.

fn fun() -> SearchResult<Socks> {
    search_drawer()?;
    search_wardrobe()
}

But in this case, the naming of the Try traits methods don't fit.

It would widen the meaning of the ? operator, though.

[cuviper]

In prototyping a try_fold for rayon, I found myself wanting something like Try::is_error(&self) for the Consumer::full() methods. (Rayon has this because consumers are basically push-style iterators, but we still want to short-circuit errors.) I instead had to store the intermediate values as Result<T::Ok, T::Err> so I could call Result::is_err().

From there I also wished for a Try::from_result to get back to T at the end, but a match mapping to T::from_ok and T::from_error isn't too bad.

[fluffysquirrels]

The Try trait can provide a from_result method for ergonomics if from_ok and from_error are required. Or vice versa. From the examples given I see a case for offering both.

[ErichDonGubler]

Since PR #42275 has been merged, does that mean this issue has been resolved?

[scottmcm]

@skade Note that a type can define whichever as the short-circuiting one, like LoopState does for some Iterator internals. Perhaps that would be more natural if Try talked about "continuing or breaking" instead of success or failure.

@cuviper The version I ended up needing was either the Ok type or the Error-in-original type. I'm hoping that destructure-and-rebuild is a general enough thing that it'll optimize well and a bunch of special methods on the trait won't be needed.

@ErichDonGubler This is a tracking issue, so isn't resolved until the corresponding code is in stable.