---
title: WG-async open discussion 2024-01-11
tags: ["WG-async", "open-discussion", "minutes"]
date: 2024-01-11
discussion: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Open.20discussion.202024-01-11
url: https://hackmd.io/YFrqx3zsTy-_x5UAgau5Nw
---

# Open discussion

Attendance: TC, tmandry, Yosh, Vincenzo, CE, Adam Leventhal, Russell Johnston (rpjohnst), Дарья Сухонина (Huawei)

Minutes: TC

## Renaming `AsyncIterator` to `Stream`

https://github.com/rust-lang/rust/pull/119550

yosh: I'd like to compare the two traits in practice since we don't have consensus, even in this group, about the path forward.

CE: I'm concerned about the lack of a bridging implementation.

CE: Also, not using pin here makes `async gen` blocks very unergonomic.

tmandry: The main value in putting this in the standard library is having some integration with language features like `async gen`.

CE: The compiler can't distinguish `.await` and `yield` b/c they both become `TerminatorKind::Yield`.

Yosh: You're saying this is how the compiler is written now, not that it's fundamentally inexpressible?

CE: Correct.

CE: Also, this seems predicated on the idea that people won't hold references across references. But I think people want to write loops, etc., in these blocks.

Yosh: This is an existing limitation of `gen` blocks.

TC: But those aren't stable yet. We could choose the solve the problem there also.

tmandry: I'm mostly aligned with what TC and CE are saying here. I think we'll want to hold references across yield points.

CE: E.g., the `for` desugaring could add a `pin!`. The async version does this now.

tmandry: How would we handle, in an await context, how would we handle?:

for x in &my_iter {}       // sync version
for await x in &my_iter {} // async version

CE: You have to pin the outer async gen. You can't take a self ref in a block.

tmandry: There's a lot that hinges on whether we want borrowing across yield points. I wonder if we can experiment with that in a way that doesn't require a separate thing. E.g., we could add a feature flag.

Yosh: My main push here is that there should be symmetry between synchronous and asynchronous Rust.

tmandry/TC: +1, they should be consistent.

Yosh: We should also think of the emergent system for things such as `try async gen` blocks. We should try the fallible version, the lending version, the pinned version, etc. How do we want to navigate this? That's why I want to experiment with this. We should get answers here.

tmandry: My worry is that in order to get that, we have to actually build them.

TC: One thing we can do is to experiment on top of Rust without building it into rustc. Many of these can be built separately on top of coroutine, and e.g. I've variously posted these prototypes to the discussion threads.

tmandry: ...

Yosh: Pinning is sound, it works today. But it's a hard thing. But I'm not sure we can address the broader challenges we have without addressing the limitations of our pinning system. We could ask, e.g., how far can we get without holding references across yield points.

tmandry: What is a set of the concrete questions that we're trying to answer. One is whether we can get away with not pinning. It'd be good to have a set of questions that we're trying to answer with the experiment.

TC: What if rather than renaming, we added this experiment under a different name? Some of the concerns related to arbitrarily breaking nightly users.

tmandry: E.g., `AsyncNextIterator`.

CE: We should be sure that it's clear the point of this experiment is more than just, "which trait is it easier to write impls for?" Because that's obvious, but that's just one angle. There's also the user experience and other concerns. I think most people are using the traits, not writing impls for them.

Yosh: On the point of what people will write more often, we should keep in mind that we're writing a systems programming language. We have to be good at every abstraction level. We should ensure that the ergonomics of the lower level of abstraction are equally good.

CE: My converse option is that Rust is good at encapsulating the hard parts into things that people can use conveniently. I do think the usage ratio, e.g. the log of it, matters. We should of course make the ergonomics good at every level.

TC: We also shouldn't take for granted that it's always easier to write the `async` version as compared to writing the more manual version. Often handles the `Pending` state explicitly is easier.

Yosh: Someone did an analysis on this: https://github.com/Kobzol/async-iterator-examples (analysis to be pending, he told me this over DMs; he wants to finish this out first, then will add an analysis overview to the project).

tmandry: What I'm missing is what are the specific claims we want to show with this experiment.

Yosh: I want to build all the things and see whether we like them.

TC: What if we try to answer tmandry's point here in this meeting:

- Whether the Self type is pinned?
- How often people are using the traits versus implementing them?
- ...or looking at them?
- How does this compose with fallibility?
- How does this compose with lending?
- How does this relate to synchronous generators and iterators?
- Can we demonstrate "portability" across synchronous and asynchronous Rust and how we'll do that?
- Can we write bridging implementations across these traits?
- This may be a result of conflating `poll_next` vs `async fn next` and whether or not the `Self` type is pinned.
- The pinned one is more general.
- Do we have clarity about async Drop and how it may affect this?

tmandry: I worry about blocking async iteration behind async Drop since that may block it permanently.

Yosh: Huawei is putting 2 FTEs toward implementing async Drop. So there is progress. It won't be permanent.

CE: Just because people are working on something doesn't mean that it will definitely happen. My hope is that we'd quickly come to the conclusion these features don't interact, or at least, that they don't interact in a way that's stronger than the way they interact with regular `Future`s, because if there is that equivalence, then we'd need to fix it anyway.

Дарья Сухонина: Async Drop is related to linear types, at least a bit. There has been discussion that linear types may in fact be easier to implement. I have thoughts about an unsafe `Leak` trait. There was a blog post about changing the rules of Rust. There were, I thought, some basic misconceptions about what `Leak` is or should be. The core problem is that you can send a value to another thread that may have some undecideable algorithm....

Yosh: We may be getting too much into the weeds.

Дарья Сухонина: In short, this new formulation of the `Leak` trait would allow use of `Rc` and channel synchronization primitives. If you want to guarantee that your drop is safely run, you must prohibit these things for a type, and that might be limiting. A safe variant of async Drop is something where values could be forgotten. I'm working on writing a post about this.

TC: We all look forward to reading that post.

tmandry/all: +1.

TC: On the main issue here, let's say that we don't rename the trait but add a new one, e.g. `AsyncNextIterator`, and we write down the findings we want from the experiment, do we have consensus to move forward on the issue?

tmandry: +1, yes, we could go forward then; I'm still uncertain about these goals.

CE: I've nominated this for T-libs-api also. We should write down these points.

TC: It feels like we should develop a consensus as WG-async to help out T-libs-api by expressing our view as a group about how to move forward.

(The meeting ended here.)