Tracking Issue for `task::Waker::noop`

[SabrinaJewson]

Feature gate: #![feature(noop_waker)]

This is a tracking issue for task::Waker::noop, a way to easily crate task::Wakers that do nothing.

Public API

// core::task

impl Waker {
    #[must_use]
    pub const fn noop() -> &Waker { /* … */ }
}

Steps / History

• Implementation: Add task::Waker::noop #96875
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Should we also add RawWaker::noop()? (I don't think so, I can't think of a use case for it)
• Should we also add Context::noop()? Depending on the direction Context goes a “noop context” might not even make sense in future.
• Should it be an associated constant instead? That would allow for let cx = &mut Context::from_waker(&Waker::NOOP); to work on one line (without additional local variables) which is convenient.
  • The return type of Waker::noop() has now been changed to &Waker.

[JarredAllen]

+1 on this feature, I find myself re-implementing a noop Waker frequently.

As for the third question, I'd personally prefer either an associated constant or changing the return signature to fn noop() -> &'static Waker;, because the only use I have for it involves immediately shoving it into Context::from_waker, which is more convenient with either of those signatures, though I'm not sure if other people have other use cases that are made easier by a function returning an owned value.

[traviscross]

@rustbot labels +I-async-nominated

Let's discuss this in a WG-async meeting as this has come up in the context of #101196.

[yoshuawuyts]

Speaking just for myself here: to me this seems generally useful as a utility, somewhat akin to future::pending and iter::empty. But I wonder whether instead of exposing it as a method on Waker, it might make more sense to create a new free function for it? That would place it a bit off the hot path, and more in the utilities section.

This would basically be a shorthand for creating a waker from Arc via the Wake trait, but minus a bit of overhead when cloning it.

[traviscross]

We discussed this in the WG-async triage call today. While everyone did see use cases for this, some also had concerns about this potentially being misused. E.g. someone might use this when the person should instead call .await. No-one seemed to think that was a blocker by itself ("Rust has lots of hard things"). Some were also unsure whether this was worth it and whether the cost of duplicating this code might actually induce a useful friction.

We were curious to hear more about the use cases. If people here could help to fill in the details of the various use cases for this, that would help with discussion, and it may help enable a WG-async consensus to form.

[Ralith]

A use case today, from quinn: I want to send a UDP datagram if doing so would succeed immediately, or otherwise drop the datagram entirely, because it's a response to a cheap request I know the peer will retry. It'd be convenient to be able to express this through a normal async UDP socket interface.