# Reading club notes: AsyncIterator

###### tags: `reading-club`

## Docs

* https://without.boats/blog/async-iterator/
* https://without.boats/blog/generators/

#### See also

* [AsyncIterator thread in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/AsyncIterator)

Leave questions, observations, discussion topics below.

---

## Topic

name: prompt

# Async iterators

nrc: one thin which I didn't notice for a while, but which is obvious in retrospect is that `async next` and `poll_next` are fundamentally different in that the former is a function which creates a future on each iteration and the latter is a special kind of thing which combines future-ness and iteration

tmandry: Right, I didn't realize how the rest of the properties being talked about fall out from that until recently.

## Fundamental-ness

tmandry:

## Other

nrc: Takeaway is that things are more complex than I thought around iteration, and that generators have a bigger role than I thought, not sure a cute desugaring.

nrc: Perhaps we should focus on generators ahead of stabilizing AsyncIterator, in order to have a well-informed design.

# Generators

## yield from

nrc: I think boats is right that using `for` is good enough (actually I think it is better since it means less syntax). Are there examples where `yield from` actually yields much better code?

tmandry: Hadn't seen it before.

yield from in python: https://stackoverflow.com/questions/9708902/in-practice-what-are-the-main-uses-for-the-yield-from-syntax-in-python-3-3

nrc: These confused me in python

tmandry: Looks like they have some utility in working around edge cases in Python generator uses, wouldn't apply to Rust though.

## return and ?

nrc: I think this is interesting because it is about combining two 'effect sugars'. There is the illusion that Result is first class and the illusion that generators are first class and its unclear how the illusions should interact. IOW, this seems like a pure human factors aspect of PL design rather than a logical/correctness aspect.

I agree with Boats that generators should return `()`. But I wonder if to use `?` in a generator the generator should yield a Result/Option rather than return it? So ? desugars to `yield` rather than `return`.

tmandry: Seems like they agree with you

nrc: But they're saying that after the yield the iterator would stop, which I don't think it has to do.

nrc: You have two kinds of iterators where something goes wrong and that's the end, and you have iterators where something can go wrong but it's not the end.

tmandry: My instinct is that the "`?` finishes the current function" should hold.

nrc: Suggests that yielding and returning is right.

tmandry: Although I don't know how this would generalize to coroutines.

nrc: Generators tend to simplify; IME coroutines tend to make code complex. But we should answer the question of whether we want coroutines.

## The `?` return question in the post

tmandry: Noodling a bit.. does a generator have to yield an Option at all? Could returning from the generator be translated into `Iterator::next()` returning `None`?

..nevermind, I think that was a misreading of the post.

My intuition: You want forwarding of `?` to work from within generators.

## Self references

nrc: option 1 seems the only one which is feasible to me. Are there realistic use cases for self-referential iterators? I couldn't think of any when I was noodling about this ealier.

tmandry: How often do we see `for x in &v`?

nrc: c.f., `for x in v`

for x in &v {
    yield x;
}

(or `v.iter()`)

there are definitely cases where I've need to write this. Maybe because I was using combinators in a particular way?

nrc: Why would you write that in a generator?

tmandry: Hard to say without experience writing generators :). But it feels pretty common in Rust.

tmandry: Maybe the most reasonable thing for us to do is to push for people to try out non-self-referential iterators and see if it works.

nrc: Also seems easy to make them self-referential in nightly later on.

---