Add read_async to Resource
#5088
Conversation
ealmloff
added
breaking
| // Can await the waker to be woken. | ||
| // We use `.peek()` here to avoid reacting to changes in the underlying task_rx which could lead | ||
| // to an effect/future loop. | ||
| impl<T: Clone + 'static> std::future::Future for UseWaker<T> { |
There was a problem hiding this comment.
This makes the change breaking. Could you restore this and mark it as deprecated so we can remove it in the next major release? We may need to remove IntoFuture
There was a problem hiding this comment.
Unless I am missing something, if we restore this, then we have to remove IntoFuture. If we remove IntoFuture then the bug in the future implementation for UseWaker remains. If this is considered a breaking change, then removing Future directly on Resource should also be considered a breaking change?
It may come down to this being an acceptable "breaking change". The only code this would break is if someone did something like let x: UseWaker = use_waker.into_future(); (now needs to be let x: UseWakerFuture = use_waker.into_future();), which I imagine never happens in practice. Code like use_waker.await or resource.await is unaffected. I know libraries like tokio have done these type of breaking changes in the past, I think this may be one of those cases we don't have to be religious about semver.
2 participants
There currently is no ergonomic way to
awaitResources in an async closure. This PR adds theread_asyncmethod toResource