{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreif2yxhk4vryygnh4hwaaak2kpkrwzdiuucahc2lcznpu4osudi3xe",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkvfhiz2d7i2"
  },
  "path": "/t/discussion-alternative-syntax-for-async-iteration-for-async-i-in-stream/24218#post_5",
  "publishedAt": "2026-05-02T18:13:40.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "C# - Iterating with Async Enumerables in C# 8 | Microsoft Learn"
  ],
  "textContent": "scottmcm:\n\n> FWIW, other languages also uses `await` here. For example, `await foreach` in C#: C# - Iterating with Async Enumerables in C# 8 | Microsoft Learn.\n>\n> `async` is for \"this is a thunk\", but that's not what's happening in a for loop.\n\nFair point on C#, but Rust's design philosophy often excels when it diverges from other languages to favor its own strengths: **patterns and bindings.**\n\nWhile `await` describes an imperative action, `async` in `for async i` describes the **nature of the binding**. In Rust, where we use patterns like `for &x in ...`, treating asynchrony as a property of the data flow (the binding `i`) feels more \"Rust-y\" and forward-looking than just adding an imperative `await` keyword because others did.\n\nLet's prioritize semantic consistency with Rust's own `async` ecosystem over following the `await foreach` precedent.",
  "title": "[Discussion] Alternative syntax for async iteration: `for async i in stream`?"
}