Allow `?` operator on `std::task::Poll`?

1

I'm not sure how useful this would be in practice, given that you'd likely use the async/await syntax instead, but should the following be allowed/possible and if not: Why not?

I don't know enough details about pin project (and future changes to improve its usability), so I don't really know how useful this'd be for those implementing a Future (combinator) in practice.

use std::task::Poll;

pub fn foo() -> Poll<()> {
    bar()?;
    Poll::Ready(())
}

fn bar() -> Poll<()> {
    todo!()
}

the ? operator can only be applied to values that implement Try

2 Likes
2

That would conflict with the existing Try implementations that "lift" an inner Result out of the Poll: Poll in std::task - Rust

3

You can use the ready! macro instead.

2 Likes
4

In retrospect, I think the one you're proposing here would have been a better one -- the nested ones are a bit odd conceptually, even if they were convenient before -- but as mentioned that's probably not going to change now.

11 Likes
5

Doesn't the fact that the existing Try implementations are experimental nightly features mean that they could be removed if a better solution was proposed?

6

How they’re implemented is unstable as are all Try implementations, but you can use them on stable via the ? operator.

4 Likes
7

In theory, over an edition, we could make ? work using a different mechanism, and in doing so make it no longer use the Poll<Result<...>> impls.

It's worth considering, but it would be a source of complexity.

8

It'd be pretty easy, I think -- use the edition of the ? token to pick the desugaring, so we can use a never-stable internal trait on old editions, then on new editions use a new stabilization-track one with different implementations.

(More details in https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#compatibility-with-accidental-interconversions-if-needed.)

1 Like