Hi,
I am requesting a formal review of P4003R3, "A Minimal Coroutine Execution Model." It is published in the May 2026 mailing, so it is eligible under the rules, and I would like it read closely before it next goes to LEWG.
**1. Is it worth standardizing?** Does this belong in the standard, or can it live as a library? The central claim is that a small normative protocol unlocks a large amount of interoperable user code (the "What We Get" table in Section 2). Is that interoperability argument convincing? Is the benefit worth the committee time and the standard surface it would consume?
Yes. This is the foundation of having coroutines with the right semantics for I/O (without the "everything here wants to eat me" feeling you have with Asio). My experience with Capy/Corosio has been positive regarding simplicity and efficiency. Many basic pieces of functionality (I/O) can be built on this, and having one standard model for it is positive.
**3. What is the technical quality?** Are the concepts sound and precisely stated? Do the central claims hold up - zero per-operation allocation under type erasure, symmetric-transfer resumption, automatic frame-allocator propagation, and the structured-concurrency argument in Section 5? Is the implementation evidence (Capy, Corosio, the benchmark table, the Compiler Explorer demo) credible and reproducible? Where is the reasoning weakest?
All the concepts are sound but the paper is extremely not self-contained. I happen to know about these concepts and could follow, but I doubt people that haven't used Capy can get much from this paper without reading p4172r0 [1] first. As an example, consider on_work_started/on_work_finished, required by the proposed Executor. These are used for work counting (prevent io_context::run() from returning until every operation has finished). There is no mention to this concept, yet the functions are there. I haven't found anything on p4172r0 either (although I haven't read it entirely). Maybe this is how these papers work. I don't know. But if I were a reader, I'd prefer external references for details, not for the semantics of the thing I'm being asked to standardize or not. Section 5.1 shows a counting_scope implementation based on run_async() and its handlers, then states that capy::when_all() is a full implementation of that approach. To me, this suggests that when_all() is implemented in terms of run_async() and its handlers, which I don't think is true. Also, all the counting_scope functions are marked noexcept, which I don't think should be. Section 3.5 includes a benchmark table, but it doesn't say what you are benchmarking, under which conditions, or what code could be used to reproduce it. Section 6's table includes the "preallocated awaitable" term, which I don't think is well-known. I assume it refers to an optimization in any_read_stream and friends. Some explanation would be useful. I'm not convinced by how section 3.1 frames the problem. IMO "co_await f();" doesn't immediately ring a bell on executor affinity. "co_await stream.read_some(buf)" does. I'd go something like: - You call co_await stream.read_some(buf) - The platform reactor (event loop) starts the work. - The operation completes. The event loop may be multi-threaded, and there is no guarantee on which thread will dispatch the completion. - BUT we have our protocol, and that saves the day. Just my 2 cents.
**4. What is missing?** What would you need to see before LEWG could act on this? I am looking for gaps in specification or wording, unaddressed edge cases, missing comparisons (against existing coroutine task libraries, or other parts of `std::execution`), lifetime or cancellation corners, threading hazards, and anything the paper moves past too quickly. Tell me what you went looking for and did not find.
I'd say include the minimal semantics of what you're asking the readers to standardize. Also, the paper seems to contain no wording for the standard - should it? I'm no expert in the standardization process.
**2. Did the use of AI affect your perception?** This paper, and the review program you are reading this on, were developed with heavy AI assistance, and I am not hiding that. I want to know candidly whether knowing or suspecting that changed how you read it. Did it raise or lower your trust? Did you go looking for tells, and did you find any? Did it make you more or less rigorous than you would be with a paper written entirely by hand? I would rather you name this in your review than leave it unsaid. The answers matter as much to me as the technical feedback, and they will shape how the Network Endeavor and this program handle AI-assisted work.
I intentionally deferred this to the last point. Yes, negatively. Aside from the LLM-isms that Matt already pointed out, my impression is that this was written by an LLM with a lot of context on the Capy project, and it assumes that the reader also has this context. IMO this makes reading it less enjoyable. I find LLMs incredibly useful for error checking and text improvement (also because I'm not a native English speaker), but I get frustrated when generating content because of this kind of thing. Regards, Ruben. [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4172r0.pdf