[kevingadd]

Part of the complexity here is the temporary object allocation and the need to read properties out of it as you iterate. This is one of the things I tried to push back on but the spec people were in a hard spot, since JS doesn't have native multiple return values. I think in ideal circumstances the allocation can be optimized out by doing store-to-load forwarding on the properties, but in cases like the post here since inlining can't happen, no such luck. :(

[conartist6]

I'm working on a new (unauthorized) iteration protocol (Symbol.streamIterator) to bridge the yawning chasm between sync and async iteration. After reading this I thought perhaps I might be able to flatten out my protocol to get rid of the objects, but funny enough they serve a much more concrete purpose in stream iteration than they do in either normal sync or async iteration: they allow you to distinguish between `next => Promise.resolve({ done, value })` which means "wait for this before continuing" and `next => ({ done, value: Promise.resolve() })` which means "the data being yielded is a promise, but the iterator is ready to proceed immediately." Huge stacks of pointlessly complex kludges (like the web streams API) have already accumulated as a result of this bedrock protocol being absent from the language.