Hello > It's 1.6k lines so it might help a little bit Yeah :)
> Why do you need reactor for this specific part of proposal? The thing is that > there shouldn't be any IO so you reduce scheduler code as well and make it > simpler and more reviewable. So you are suggesting removing all I/O from the RFC. On the one hand, that sounds appealing. It immediately eliminates a bunch of tests. But there is a trap we could all fall into. By separating the reactor and the scheduler, as well as the rules of how they work together, we might accidentally introduce an error into the document simply because the documents would be split. (interface drift) The fact that the I/O rules and coroutine rules are part of a single document developed together is actually an advantage, just as the existence of separate RFCs for await and Scope is. And this does not prevent splitting the implementation code into many small parts. On the other hand, STREAM has corner cases, especially in error situations, that would be appropriate to discuss and formalize in a separate RFC. Ideally, this should probably be done right before accepting the STREAM PR. However, such a description does not carry significant risks. This requires some thought.
