{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreih72zg7lclzdgrtq5fqiqzachbtqg4lo44542cgesx2wjjjelrdi4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkvfi3mbjvl2"
  },
  "path": "/t/discussion-alternative-syntax-for-async-iteration-for-async-i-in-stream/24218#post_3",
  "publishedAt": "2026-05-02T18:07:31.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Thanks for the insightful feedback! You’ve hit on the core semantic tension here.\n\nI agree that in `async fn` or `async {}`, `async` acts as a \"wrapper.\" However, I’d argue that in the context of a **binding site** (like `for <pattern> in <stream>`), `async` can be naturally extended to mean **\"this binding is resolved asynchronously.\"**\n\nA few counter-points to consider:\n\n  1. **Async Patterns vs. Async Wrappers** : In a `for` loop, the `i` is a pattern. Just as `&i` in a loop destructures a reference, `async i` could be seen as \"destructuring\" (or resolving) an asynchronous value. It tells the compiler: \"The source is async, and we are binding the resolved value to `i`.\"\n\n  2. **The \"Wait\" is implicit in`for`**: The `for` keyword already implies a sequential progression. Adding `await` feels like describing _how_ the engine works (imperative), whereas `async` describes the _nature_ of the data being bound (declarative).\n\n  3. **Avoiding the \"Future of Option\" confusion** : You mentioned `Option<Future<...>>`. My proposal doesn't change the underlying `AsyncIterator` trait (which remains `Future<Output = Option<T>>`). Instead, it’s about how we denote the **suspension point**.\n\n     * `for await i`: \"Wait, then bind.\"\n\n     * `for async i`: \"Bind the result of an async step to `i`.\"\n\n\n\n\nIf we eventually get `let async i = ...` for destructuring futures or handling async drop, `for async i` becomes perfectly consistent. It marks the **boundary** where asynchrony is handled, rather than just being a label for the `await` operation itself.",
  "title": "[Discussion] Alternative syntax for async iteration: `for async i in stream`?"
}