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