{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigdcqw7lwggxtpwnjtco2ggyx6xy4v5tssfw6qtru7ncprzoivkgm",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkvfi7obp4c2"
  },
  "path": "/t/discussion-alternative-syntax-for-async-iteration-for-async-i-in-stream/24218#post_1",
  "publishedAt": "2026-05-02T17:40:54.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "withoutboats' blog post"
  ],
  "textContent": "### Hi everyone,\n\nWhile the community has been gravitating towards `for await i in stream`, I’d like to propose considering **`for async i in stream`** instead.\n\nMy core argument is about **declarative vs. imperative mental models** :\n\n  1. **Symmetry with Async Closures/Blocks** : We already use `async move || {}` and `async {}` to define asynchronous contexts. Using `for async i` treats the item `i` as an **async binding**. It signals that the source is asynchronous by nature, rather than just adding an imperative \"wait\" step at the top of the loop.\n\n  2. **Patterns, not Actions** : `for await` feels like a command (loop and wait). `for async i` feels like a pattern (for each async item). This aligns better with potential future features like `let async x = ...` (async pattern matching or async drop).\n\n  3. **Reflecting the Stream's Nature** : Just as `async fn` describes a function that yields a future, `for async` describes a loop that consumes an asynchronous producer. It keeps the syntax focused on the **type of iteration** rather than the low-level polling mechanism, staying true to Rust's goal of \"zero-cost abstractions\" for the mind.\n\n\n\n\nI feel `for async` is more \"Rust-y\" in its declarativeness and provides a more cohesive aesthetic with the rest of the `async`ecosystem.\n\nWhat do you think? Does `for async` capture the intent of stream processing better than `for await`?\n\n----\n\n**Quick note on context:** I’m aware of the previous discussions comparing `async for` and `for await` (e.g., **withoutboats' blog post**). However, I want to clarify that **`for async i`** is distinct from the older `async for` proposal.\n\nWhile `async for` was often discussed as a way to define the entire loop context, my proposal focuses on **async pattern matching/binding** at the item level. It aims to bridge the gap between \"how we poll\" (`await`) and \"what the data is\" (`async`). By using `for async`, we treat asynchrony as a property of the iteration binding, which I believe avoids some of the syntactic weight of `for await` while remaining more declarative than the \"block-level\" `async for`.",
  "title": "[Discussion] Alternative syntax for async iteration: `for async i in stream`?"
}