On 6/18/2026 8:17 PM, Vinnie Falco wrote:
Colleagues,
I am requesting a formal review of P4003R3, "A Minimal Coroutine Execution Model." [...]
What I am asking you to evaluate
[...]
**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?
The main reason to standardize is real. Today, each coroutine library defines its own task type, and tasks from different libraries cannot be mixed together. The companion paper answers how this differs from `std::execution`. So, yes, I think the benefit is worth the committee time and standard surface consumption, provided the open questions below are addressed. I'm just not sure the protocol is "minimal" :-).
**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.
Knowing it was AI-assisted made me more careful, ignoring the confident tone and checking each claim. But I found no invented APIs and no fake citations.
**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?
The concepts are written as real C++ and are mostly clear. About the central claims: - Zero per-operation allocation under type-erasure: holds up; appendix B of the companion shows working code for it. The comparison table is set up in a way that favors coroutines, but the point is valid. - Symmetric-transfer resumption: correct and standard. Minor point: there's a small runtime check, so "zero overhead" is slightly too strong. - Automatic frame-allocator propagation: I'm concerned about the method (thread-local pointer that is saved and restored). IIUC, it only works if every place that resumes a coroutine remembers to save and restore the pointer. Nothing forces this, and one mistake means a frame is allocated from the wrong allocator with no error reported. Is my understanding correct? - Structured concurrency (section 5): the paper says the protocol *is* structured concurrency, but it also allows an unstructured fire-and-forget launch. It also says cancellation is automatic, but its own examples require the programmer to check the stop token manually. Again, I may be missing something here. As to reproducibility, I ran the Compiler Explorer demo, but could not find the benchmark sources.
**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 wonder about the following:
- Who owns the `io_env` in a fire-and-forget launch. The stated lifetime rule does not cover this case. - The cancellation details: how a stop request reaches a running operation, and how the race between normal completion and cancellation is handled. - An example that shows how this protocol would solve the interoperability problem among existing coroutine task libraries. - The memory cost of `std::stop_token` compared with an in-place stop token. -- Gennaro Prota <https://prota.dev>