Doesn't this just replace the "slow if next() is complex" with "slow if the body of the loop is complex"? A complex iterator does have the problem of having the

Doesn't this just replace the "slow if next() is complex" with "slow if the body of the loop is complex"? A complex iterator does have the problem of having the allocation for its result, not being able to directly branch on the `done` computation, but the usage body could also have drawbacks from not being inlined with its scope (though of course if you know that next() is sufficiently complex, there's largely no downside to at least try the other way around). Also, depending on the VM implementation, it might run into issues if you use the same iterator-function with many different callbacks, if there's a limit to how many different values for the callback argument it specializes; don't know what exactly the limits or effects are, but in some simple testing, both Node/V8 and FF/SpiderMonkey slow down on a callback-based-iterator bench if before the main bench the "iterator" was used with multiple different callbacks (whereas the inverse of a single loop iterating through many different iterator types is probably quite a bit more rare).