On Sat, Nov 15, 2025, at 23:06, Edmond Dantes wrote: > > I guess my main thing is that this RFC should only cover coroutine > > machinery: it should not promise "transparent async" or "code > > It’s like trying to dig a hole with half a shovel :) > > > that works exactly the same" OR if it wants to make those claims, it should > > actually demonstrate > > how instead of hand-waving everything as an "implementation detail" when > > none of those claims can actually be validated without those details. > > All of my claims are backed by tests :)
I will leave with some final advice. The problem with tests is that they only validate the current implementation, which isn’t guaranteed to be the final implementation. I would recommend reviewing your tests and matching up each of them to where you mention that behavior or define it in the RFC. If the tests are implementation-specific, then it needs to be defined in the RFC. For example, you say that the scheduler is 100% an implementation detail, but your outputs in the tests rely on a specific ordered queue. You should at least define the ordering the queue should be processed in the RFC (LIFO vs FIFO) so that even if the implementation changes, the tests still pass. That’s one example, you can review my previous comments to discover other examples, such as defining the rules of suspension points. I wish you the best, — Rob
