---
title: "Design meeting 2024-04-18: Async iteration/generation"
tags: ["WG-async", "design-meeting", "minutes"]
date: 2024-04-18
discussion: https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Design.20meeting.202024-04-18
url: https://hackmd.io/Ed0DtZ2KRGuBa0wCjNet9g
---

# Discussion

## Attendance

- People: TC, eholk, Daria, Yosh

## Meeting roles

- Minutes, driver: TC

## Last week

TC: Our minutes from last week on this subject are here:

https://hackmd.io/bYaPiCdqR3WIyjKhFWzdtQ

## Current state: Low level desugaring

TC: On the basis of recent discussion, it seems we've reached agreement on the low-level desugaring.

E.g.:

pub trait AsyncGen {
    type Item;
    fn poll_next(self: Pin<&mut Self>, cx: &mut Context) -> Option<Self::Item>;
}

pub trait IntoAsyncGen {
    type Item;
    type IntoAsyncGen: AsyncGen<Item = Self::Item>;
    fn into_async_gen(self) -> Self::IntoAsyncGen;
}

Yosh: At the lowest level, I agree this is what we need to pull it forward.

TC: That leaves these known open questions:

- Whether or not to allow the traits to be named.
- whether or not we stabilize the methods on `AsyncGen` or `IntoAsyncGen`.

## Reconsidering lowering question

Yosh: Since last week Oli showed that the presented applies to Futures generally. So I'm reconsidering the lowering question.

TC: That argument was:

(Pasting arguments from Oli who is not in this call.)

Oli: How would the for loop look with a simple initial desugaring to a `loop` and a `match`

let iter =...;
// unclear if needs to be an async operation
let mut actual_iter = iter.into_async_foo();
loop {
    let output = actual_iter.something_next().await;
    // ???? how to get output?
    match output {
        Some(x) => {
            println!("{x}");
        }
        None => break,
    }
}

Minor issue: method call syntax is problematic due to being able to invoke random other things of the same name

let iter =...;
// unclear if needs to be an async operation
let mut actual_iter = IntoAsyncFoo::into_async_foo(iter);
loop {
    let output = AsyncFoo::something_next(&mut actual_iter).await;
    match output {
        Some(x) => {
            println!("{x}");
        }
        None => break,
    }
}

problem: HIR cannot support `await`. So we need to desugar the entire `for..await` block in one step:

let iter =...;
// unclear if needs to be an async operation
let mut actual_iter = IntoAsyncFoo::into_async_foo(iter);
loop {
    let output_future = AsyncFoo::something_next(&mut actual_iter);
    // can access `current_context` here, because we're in a HIR desugaring context
    // async desugaring copied from: https://doc.rust-lang.org/stable/reference/expressions/await-expr.html
    let output = match output_future {
        mut pinned => loop {
            let mut pin = unsafe { Pin::new_unchecked(&mut pinned) };
            match Future::poll(Pin::borrow(&mut pin), &mut current_context) {
                Poll::Ready(r) => break r,
                Poll::Pending => yield Poll::Pending,
            }
        }
    };

    match output {
        Some(x) => {
            println!("{x}");
        }
        None => break,
    }
}

needs dyn star, always has double references, optimizer has problems with large `output_future` and complex `Future::poll` methods (can't optimize out). The following is already fairly optimal by default, so the optimizer can concentrate on cleaning up the loop just like it does with sync for loops.

let iter =...;
// unclear if needs to be an async operation
let mut actual_iter = IntoAsyncFoo::into_async_foo(iter);
loop {
    // can access `current_context` here, because we're in a HIR desugaring context
    // async desugaring copied from: https://doc.rust-lang.org/stable/reference/expressions/await-expr.html
    let output = match output_future {
        mut pinned => loop {
            let mut pin = unsafe { Pin::new_unchecked(&mut actual_iter) };
            match AsyncFoo::poll_next(Pin::borrow(&mut pin), &mut current_context) {
                Poll::Ready(r) => break r,
                Poll::Pending => yield Poll::Pending,
            }
        }
    };

    match output {
        Some(x) => {
            println!("{x}");
        }
        None => break,
    }
}

eholk: The compiler struggles to optimize futures, and that's just true. It's a compiler limitation. You could imagine adding some heuristics or special optimizations that try to do better in these cases.

Yosh: It feels like since this is already a problem, we'd not be adding any new problems. It'd just take time and effort.

eholk: It's possible that putting more weight on this problem would cause it to solve it sooner.

Yosh: Oli's estimate was someone full time for two years.

eholk: Oli's estimate seems in the right ballpark to me.

Yosh: Apparently pnkfelix tried awhile back and decided this was hard.

TC: There's always risk in betting on our ability to write a sufficiently smart compiler. Any estimate on the scale of two years of full time work has the potential for many hidden landmines. If we were so certain on how to do this as to be sure there are no landmines, then the estimate would probably be a lot shorter than two years.

Yosh: I think the right call here is to ask Oli to clarify; I don't think we should pessimize what he said either.

Yosh: Two things I'm unsure of:

1. Should the lack of optimization of futures in the general sense dictate the shape of what our generator blocks desugar into forever after? If this is a shared problem, do we expect to eventually resolve this? If we do not, is this worse than what is the norm for all other async functions?
2. What happens when you go from AFIT `async fn next` to a `dyn AsyncIterator`. Can we escape the double deref / double indirect call?

Yosh: These are the only two convincing arguments in favor of `poll_next`.

## Meta

(We had a long meta discussion related to how to make this issue less stressful for everyone. We agreed to repurpose the design meeting slot next week for an open discussion.)