On Sat, Nov 15, 2025 at 11:03 PM Edmond Dantes <[email protected]> wrote:
> 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) > I don't see it that way. You have already implementation showing that this is workable for the proposed user interface so it's just addition into that. I'm not sure how it could even impact user interface that is being proposed? If you are talking about internal interface, then it doesn't matter, because this can be changed (you don't have to keep BC there especially for such a new internal interface like this). > 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. > But are I/O rules really part of this document? There are just a few mentioning of I/O and that seems more like a leftover from previous version to me. I don't think it needs to keep reactor in there and mention I/O in other parts. It should just clearly put it to the future scope to make clear that this is something that is part of the plan. Kind regards, Jakub
