Change:
} #[stable(feature = "futures_api", since = "1.36.0")] <ins> #[cfg(bootstrap)] </ins> impl<T, E> ops::TryV1 for Poll<Result<T, E>> { type Output = Poll<T>; type Error = E;

Discussion:
Forgot it? Still for other reasons.
See also:
thanks
It seems to me that if should exist at all, then it should implement , otherwise doesn't work.
Facing the same issue in 2019 :/
After looking through the discussion on , I’m getting the impression that it is indeed an oversight that there is no way to convert to so that you can use on a function that returns .
This becomes a prevalent problem in the trainings I give, when people learn about: , because they also try to coerce optionals.
Can this be prioritised? It would be upsetting if this were to be forgotten, particularly since is quite useful now.
I don't believe this has been forgotten or de-prioritized -- at the very least, based on me re-read of , I get the impression that the general feeling is that the Try trait design is not ready and being convertible to via is not something we are sure we want. In particular, these comments are relevant:
I actually changed my mind on this one. Now that I think about it, it only really makes sense to use on an if the enclosing function returns an . Otherwise if you want to return a you can use to indicate what went wrong. The error message could be much better though.
I agree about the error message. I think one thing we missed in the Try trait design discussion was what the errors for mixing should look like -- right now you get the note about , but with the other possible design you would have explicitly gotten something about .
I'll note that I think the existence of a is a bit strange and a bit of a code smell, and another design should be considered. But if it isn't considered, make sure is implemented at least, haha.
If is to exist, then it should implement , otherwise a better name should be chosen for the try trait result. But generally, I think I'd like to be able to use in functions returning on either or types (without explicit conversion), while only allowing use on types in functions that return . Does this make sense?
I don't think should implement for . is not an error, it is just a state that may cause errors. If Option<Tdoes not implement , then block does not need . from
Should NoneError implement the Error trait? Just a note
I see the issue that Try for Error is already on stable.

Note that as of right now, it's absolutely by design that doesn't implement , because it's by design that you can't on in something returning . It's also unstable for a reason. We have a meeting planned about redesigning the current approach, which will likely remove from being involved in -on-. I strongly discourage anyone from trying to hack around this restriction. Just use if you want to early-return on in a -returning function.
Make any progress this year on the issue? You've mentioned "we have a meeting planned", just following up here.
Sorry for replying super-late here. The meeting was , though I'm not able to find minutes from there. But merged last week, which explicitly blocks the -on--in--functions possibility, and (as it obviates RFC 1859) will likely result in being deleted from nightly. Edit a while later: for RFC 3058 currently gives this error: Hopefully that will point people in the right direction, and avoid them ever hearing of .
What was the resolution for this? If it was resolved, what version of Rust contains the fix and how do we use it in our projects? Is there a convenient workaround that works before the fix? Forgive my questions, I'm really new to Rust and just trying to get it working.
The resolution of this is that it's expected that mixing them does not compile. has been deleted. As such, the fix is to call  or to provide a value implementing that includes the information about what went wrong, or to change the context to return instead of .