---
title: WG-async triage meeting 2023-12-18
tags: ["WG-async", "triage-meeting", "minutes"]
date: 2023-12-18
discussion: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Triage.20meeting.202023-12-18
url: https://hackmd.io/NKJ03INgT_Ou-oryLTZnZw
---

# WG-async meeting agenda

- Meeting date: 2023-12-18

## Attendance

- People: TC, eholk, Vincenzo, CE, Yosh

## Meeting roles

- Minutes: TC

## Scheduled meetings

- 2023-12-21: WG-async holiday party

Update these [here](https://github.com/orgs/rust-lang/projects/40/views/1).

## Proposed meetings

None.

Update these [here](https://github.com/orgs/rust-lang/projects/40/views/1).

## Announcements or custom items

### Extending triage meeting to an hour

eholk: We had proposed to extend this to an hour; did we finish that discussion?

TC: We had not, thoughts?

CE: Async conversations proceed more slowly, so it might be easier. I don't see a problem in extending it.

Vincenzo, eholk, TC: +1.

*Consensus*: Let's extend the meeting to an hour, starting today if required.

### Next triage meeting on the 8th

TC: Our next triage meeting would have been scheduled for the 1st. Let's push it one week to the 8th.

all: +1.

*Consensus*: We'll next do triage on the 8th.

### Meeting on Thursday the 21st

TC: We had said we'd decide today whether to meet on Thursday.

eholk: Is there a way to do a WG-async holiday party?

TC: I second that. Let's do a WG-async holiday party on Thursday for those interested.

*Consensus*: We'll meet on Thursday.

## Untriaged issues

### "type inference fails when using `async_fn_in_trait`" rust#108362

**Link:** https://github.com/rust-lang/rust/issues/108362

CE: This may not be possible to fix.

CE: I believe this is due to `.await` desugaring introducing too much indirection.

CE: This is not an `IntoFuture` problem.

CE: To investigate, someone should manually desugar `.await` to see where the ambiguity is originating.

*Consensus*: We'll leave a comment to that effect.

---

After the meeting, CE noticed a flaw in our analysis and posted on the issue. He plans to investigate further.

### "Support async recursive calls (as long as they have indirection)" rust#117703

**Link:** https://github.com/rust-lang/rust/pull/117703

CE: Nothing to discuss here.

TC: Agreed this is in FCP. We'll mark as triaged.

*Consensus*: We'll mark this as triaged.

## Nominated RFCs, PRs, and issues

### "Tracking Issue for `task::Waker::noop`" rust#98286

**Link:** https://github.com/rust-lang/rust/issues/98286

In the issue, during our meeting, Yosh proposed:

> 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.

TC: We discussed this on the last call. eholk had some concerns about this. It feels like eventually it would be good for WG-async to express a +1 or -1 here.

eholk:

My thinking was, it's currently hard to write a `Waker`. Sometimes I'm tempted to call `poll` on a future directly, but then I have to conjure up a `Waker`. On the other hand, if I'm writing `poll` in the right context (basically inside another `poll`), then I have a `Context` in scope and it's easy to create wakers there.

I guess the worst case is that people start writing inlined `block_on`s instead of using `.await`.

I guess it could also be misused in future combinators. Normally you want to do something with the waker provided to you, but having a `noop` waker could make it easier to just use a noop one, which could lead to not getting awoken because someone forgot to use the parent waker.

I definitely think it has uses!

For the use cases I'm aware of, I think it's not the end of the world to write your own no-op waker. It's easy enough to write yourself, and the extra 5 lines of code gives a chance to pause and think about whether your use is appropriate.

But I could be missing an entire class of use cases that would push me more towards not duplicating this code every time you want it.

The [future docs](https://doc.rust-lang.org/std/future/trait.Future.html) already say:

> When using a future, you generally won’t call poll directly, but instead .await the value.

I don't think "it's hard to use correctly" is a blocker. Rust has lots of hard things.

I think we don't necessarily need a wg-async decision at this point in time. It might be useful to have individual members express their opinions.

*Consensus*: We'll leave this nominated while the members think about this and perhaps discuss their own views in the ticket.

### "Tracking Issue for `Ready::into_inner()`" rust#101196

**Link:** https://github.com/rust-lang/rust/issues/101196

TC: In the last call, eholk, you dropped your concern about this poking through the abstraction.

eholk: @**Michael (compiler-errors) Goulet** persuaded me with the point that we are allowed to do more things when we know more about the underlying type (in this case the fact that we have a `Ready` and not an `impl Future`)

TC: And tmandry dropped his concern about this panicking.

TC: Still, my view is that T-libs-api should consider naming this `unwrap` due to the panicking behavior. tmandry has expressed he is OK with that name also. The original author of the PR has also expressed a preference for `unwrap`.

TC: It seems our policy is to do a *de novo* review when adding things from the `futures` crate rather than giving preference to the choices that crate made.

eholk: Calling `unwrap` in code still *feels* sloppy to me, though this feeling is probably outdated by 7 years.

TC: Interesting. That would actually argue for also having `expect` here.

eholk: The presence of `#[track_caller]` makes `expect` less necessary. That's why my feeling is probably outdated.

yosh: By comparison:

https://doc.rust-lang.org/std/result/enum.Result.html#method.into_ok

...uses `!` (never) as the `Err` path and never panics.

The method on `Ready` should be called `unwrap`.

I largely consider `Ready` to work as a special-cases alias/variant of `Option`

In `Option` terms the functionality we’re describing really is like `unwrap`

TC: So Yosh agrees with calling this `unwrap`. Anyone else agree with this as the position of WG-async?

eholk: It sounds like the high order bit of the preference is that we follow existing conventions, and we're arguing based on existing conventions we should call it `unwrap`?

Yosh/TC: Agreed, and that's a good framing.

eholk: +1 on this being the WG-async consensus.

*Consensus*: WG-async would prefer that this be called `Ready::unwrap`.

### "Add support for `for await` loops" rust#118847

**Link:** https://github.com/rust-lang/rust/pull/118847

eholk: I nominated this to make us all aware of the work.

all: Very exciting.

### "Add LocalWaker support" libs-team#191

**Link:** https://github.com/rust-lang/libs-team/issues/191

TC: We expresesd an opinion in favor of allowing experimentation.

TC: If this did proceed to stabilization, would we have any concerns?

Yosh: I'm on board with experimentation, but we should chart out limits.

Yosh: NRC noted that seeing this through may require `LocalFuture`. Since this PR doesn't do that, it probably has limitations.

eholk: I would expect something like `LocalWaker` to be viral.

Yosh: The motivation mentions a thread-local executor. That's also an unexplored area.

Yosh: I'd like to see how this interacts with `FuturesUnordered` and `FuturesGroup` (from `futures-concurrency`).

TC: Is the concern the limitations or that it might lead to more `LocalX` types? And if it did lead to that, would we consider that bad or necessary to address the use cases?

Yosh: That's the important question.

Yosh: This API makes the assumption that `Arc` is always needed. By not being viral enough, it might keep too much overhead. At work, we have ulta-high performance networking applications that can't use futures because of the overhead of creating an `Arc` for every future.

Yosh: My view is that we removed the `Send` bound from `Context` not to lock in a decision, but to enable exploration and to leave doors open.

*Consensus*: Let's leave a comment to prompt more discussion of these issues.

(The meeting ended here.)

## WG RFCs, PRs, and issues nominated for T-lang/T-types

### "`.await` does not perform autoref or autoderef" rust#111546

**Link:** https://github.com/rust-lang/rust/issues/111546

## Pending PRs on the WG-async repo

None.

## `S-waiting-on-team`

None.

## Proposed FCPs

**Check your boxes!**

### "Tracking Issue for `Ready::into_inner()`" rust#101196

**Link:** https://github.com/rust-lang/rust/issues/101196

## Active FCPs

### "Support async recursive calls (as long as they have indirection)" rust#117703

**Link:** https://github.com/rust-lang/rust/pull/117703

## P-critical issues

None.

## WG-async work project board

https://github.com/orgs/rust-lang/projects/29/views1/d