{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicp46lcfxliwzzkw6nkh544oiauwndp5zibg4hktv46h4qqkgh2ni",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkvfh7cckgn2"
  },
  "path": "/t/discussion-alternative-syntax-for-async-iteration-for-async-i-in-stream/24218#post_6",
  "publishedAt": "2026-05-02T19:21:32.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "soplwang:\n\n> Just as `async fn` describes a function that yields a future, `for async` describes a loop that consumes an asynchronous producer.\n\nI hope you see the contraddiction here: the former yields while the other consumes (just like `.await`)\n\nsoplwang:\n\n> my proposal focuses on **async pattern matching/binding** at the item level\n\nThe issue here is that streams are not `Iterator<Item = impl Future>` where you can just await each item. You have to instead `await` getting the item itself. For this reason they cannot be fit into the existing `for` machinery, and adding a new kind of binding won't change this.\n\nsoplwang:\n\n> Thanks for the insightful feedback! You’ve hit on the core semantic tension here.\n\nCan we please avoid generating posts/answers using LLMs? Or if you really want to do so at least remove the blatant parts.",
  "title": "[Discussion] Alternative syntax for async iteration: `for async i in stream`?"
}