Tracking Issue for the Wake trait

[KodrAus]

This is a tracking issue for the Wake trait.
The feature gate for the issue is #![feature(wake_trait)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

• Write an RFC for the Wake trait
• Adjust documentation (see instructions on rustc-guide)
• Stabilization PR (see instructions on rustc-guide)

Unresolved Questions

Implementation history

• Initial implementation: Add Wake trait for safe construction of Wakers. #68700.

[yoshuawuyts]

Filed a stabilization PR: #74304

[yoshuawuyts]

These are the uses the Wake trait will replace:

• RawWaker with raw pointers can be confusing for people learning about futures. Wake makes this safe and easier to follow.
• Replacement for the waker-fn crate and wakeful crates that provide a waker_fn function to easily create a waker from a closure. Example use in the blocking crate.
• Tokio uses an internally-defined Wake trait that has the same shape and use as core::task::Wake (src)
• It makes it easy to author waker-based tests with. Example from rustc, example from event-listener.

This is mostly a useful helper to enable people to safely author Waker impls through, which is useful during testing, teaching, and when you only have a single callback that needs to be called when woken.

[taiki-e]

@yoshuawuyts

These are the uses the Wake trait will replace:

I believe futures::task::ArcWake should be added to that list.