Implements wait_for()

[shikokuchuo]

Closes #142, closes #48.

As discussed in today's Shiny meeting. This PR takes an approach that works universally for any type of promise.

I need time to ponder (i) the function name, (ii) whether it should throw on rejection, and (iii) whether it is correct/optimal to set all = FALSE for later::run_now().

To add:

• Tests
• News item

In the meantime, feel free to comment @schloerke @gadenbuie @cpsievert.

[shikokuchuo]

After putting together this PR, I came across the version of wait_for() @lionel- uses internally for tests in coro. This gives me confidence in (i) the naming of the function and (ii) its behaviour on error.

[gadenbuie]

This looks like a great start @shikokuchuo! Have you reviewed the chromote implementation?

Currently this PR resembles various implementations we've used in package testing, which is a much more controlled environment. For a public, robust and final solution in promises we should be very convinced about the features we do or do not need from the chromote implementation.

[shikokuchuo]

Thanks @gadenbuie I hadn't actually reviewed chromote as I was under the impression that it wasn't an R-level implementation, let alone one based on promises! Luckily it seems we all converge on the same approach.

Chromote additionally has a lot of code to handle interrupts and my gut reaction is that this isn't necessary in the general case, but this should become apparent when I actually write the tests!

[gadenbuie]

Chromote additionally has a lot of code to handle interrupts and my gut reaction is that this isn't necessary in the general case, but this should become apparent when I actually write the tests!

I think this gets at what I meant by the difference between the implementations we've used in testing and a user-facing API. My inclination is that in user-facing code we'd want, or might even need, to support interrupts and other features that users would need and expect in an interactive session.

[schloerke]

Yes. Both @gadenbuie and I would like to have the chromote version with interrupt support.

Thank you, @shikokuchuo !

[shikokuchuo]

Just so we're on the same page, the wait_for() currently in this PR does support interrupts. At the underlying level, later::run_now(Inf) is user-interruptible without any side effects. Semantically, this is usually what we want - we're free to wait, stop waiting, or carry on waiting at any time.

The version in chromote seems to be to support the interrupt cancelling the underlying promise itself, and is specifically used together with later_with_interrupt() which is a non-exported function internal to chromote.

[gadenbuie]

Just so we're on the same page, the wait_for() currently in this PR does support interrupts.

Thanks for clarifying, that's great to hear.

The version in chromote seems to be to support the interrupt cancelling the underlying promise itself ...

...my gut reaction is that this isn't necessary in the general case, but this should become apparent when I actually write the tests!

I'm happy to wait to see what you find out when you write the tests, but it'd be helpful in the end if this PR description can include a summary of the chromote code and an explanation of why we don't need to follow the same path here. It'd also be useful to explain whether we can replace chromote's version with promises' solution without breaking backcompat.