So that I understand these type signatures correctly, this is for converting Poll<Result>s into Polls? As in, it's not quite the same as the older try_ready!, which would give me T back, not wrapped in Poll::Ready(t), right?

@seanmonstar Right, this is just like if you were to use ? in the futures-0.1 world (propagates errors, not readiness). You can combine this with the ready! macro to propagate Poll::Pending. So 0.3 try_ready!(x) maps to 0.3 ready!(x?), and 0.1 x? maps to 0.3 `x?.

I like this factoring (of just handling the error conversions here, and leaving macros for readiness projection). And in any case, 👍 for trying it out and seeing how it feels!

@bors r+

📌 Commit bce8a91 has been approved by aturon

🌲 The tree is currently closed for pull requests below priority 99, this pull request will be tested once the tree is reopened

I think it's a good idea to try this out. However, it has to prove itself. In particular I would like to see some of our combinators converted to this new style.

BTW where is the difference between:

let x = ready!(future.poll()?);

let x = ready!(future.poll())?;

I see that it's different for poll_next() though. Seems complicated

So, let's try it, but I remain skeptical

Okay never mind. I understand the difference now: from_error returns Poll::Ready(Err(e))

@MajorBreakfast

BTW where is the difference between:
let x = ready!(future.poll()?);
let x = ready!(future.poll())?;

The first one will first check for errors, return them if necessary, then check for Poll::Pending and return if necessary. The second will do the opposite order. There's no difference in the end result, since you can't have both Poll::Pending and Poll:Ready(Err(...))/Poll::Ready(Some(Err(...)))

@cramertj No I was wrong there. The second one won't actually work because ready! extracts the Result<T, E> from the Poll::Ready(_). Then, ? returns the E from the Err(_) variant which doesn't match the function's return type (Poll). Only the first one works.

@MajorBreakfast

No I was wrong there. The second one won't actually work because ready! extracts the Result<T, E> from the Poll::Ready(). Then, ? returns the E from the Err() variant which doesn't match the function's return type (Poll). Only the first one works.

When using ? on a value, that value's type doesn't have to match the return type. ready!(future.poll())?, if ready! succeeds, would be like doing ? on a Result<T, E>, which (after this PR) will work fine in a function which returns Poll<Result<T, E>> or Poll<Option<Result<T, E>>>.

@cramertj Ah I see. It seems that Try works slightly different to how I thought it would. Thx for the explainer!