Unconfined context is indeed quite simiar as to how
buildIterator operates with the only significat difference for our discussion is that
buildIterator is more lazy than
produce computes the element before
receive is invoked, while
buildIterator computes the element only when
next is invoked). But if you need a synchronous iterator, then why whould you use
produce in the first place?
So, they key conceptual difference is that
produce is designed for asynchronous coroutines (CSP, actor-model, Go-style) and giving it a default behavoir that is synchronous does not look like an appropriate choice.
The plan is to actually implement some kind of
DefaultContext (mutli-threaded, asynchronous) that is going to be better suited for this kind of workload than
CommonPool (which is designed and optimized for fork-join workloads and does not work so well for general ones). This kind of the context might become an appropriate default for all asynchronous coroutine builders.