Paper-reviews

paper-reviews@lists.wg21.org

June 2026

11 participants
2 discussions

Review request - P4286R0, "P3552: The Return of Networking TS Executors"
by Mungo 01 Jul '26

01 Jul '26

Subject: Review request - P4286R0, "P3552: The Return of Networking TS Executors" Colleagues, I am requesting a formal review of P4286R0, "P3552: The Return of Networking TS Executors," and would like it read closely. Please all read the same revision, so the summary attaches cleanly to a single document: - Paper under review - P4286R0: https://isocpp.org/files/papers/P4286R0.pdf - The framing the argument rests on - P4094R1, P4095R1, P4096R1: https://wg21.link/P4094R1 https://wg21.link/P4095R1 https://wg21.link/P4096R1 - The current papers it diagnoses - P3552R3 (the task type) and P3941R4 (the infallibility requirement): https://wg21.link/P3552R3 https://wg21.link/P3941R4 - The coroutine executor it sets beside them - P4003R3: https://wg21.link/P4003R3 - The earlier executor history it draws on - P0113R0, P1525R0, P0443R14, P2464R0: https://wg21.link/P0113R0 https://wg21.link/P1525R0 https://wg21.link/P0443R14 https://wg21.link/P2464R0 What the paper argues The paper is a diagnosis, not a proposal. It asks for nothing. In 2021 the committee set aside the Networking TS. One stated deficiency was that its executors had no way to report a failure. In 2026, std::execution::task (P3552R3) resumes after every co_await on the scheduler it suspended on, and implements that guarantee by wrapping each awaited expression in affine_on. P3941R4 then requires that a scheduler used with affine_on be infallible: it may complete only with set_value(), never set_error and never set_stopped. The scheduling operation that drives task has no way to report a failure. The paper argues that these two constraints, the one named a defect in 2021 and the one required in 2026, have the same shape. It traces the path between them through the distinction between the work framing and the continuation framing of execute(F&&) (P4094R1, P4095R1, P4096R1), and concludes that under the continuation framing an infallible scheduling operation is not a defect but the correct shape: a suspended coroutine is not running to act on an error. Section 6 sets three executors side by side, P0443R14, the P3941R4 infallible scheduler, and the P4003R3 coroutine executor, and argues they share one shape. What I am asking you to evaluate Reviews here are informational. There is no verdict and no gate, so please do not feel you are voting the paper up or down. What I would most value is an honest read on four questions. 1. Is the historical trace accurate? Does the path from P1525R0 and P2464R0 to the P3941R4 infallibility requirement hold up against the record? Are those papers characterized fairly, in particular the claim that P1525R0 and P2464R0 analyzed execute(F&&) under the work framing alone, and that the continuation framing from Kohlhoff's P0113R0 had been erased from the API surface by the time either was written? 2. Did the use of AI affect your perception? The papers in this series, and the review program you are reading this on, were developed with heavy AI assistance, and I am not hiding that. Whether or not you suspect it of this paper, I want to know candidly whether that knowledge 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. 3. Is the structural claim sound? The heart of the paper is the symmetry in Section 6: that the P0443R14 executor, the infallible scheduler of P3941R4, and the coroutine executor of P4003R3 share one shape - a scheduling operation that delivers no value and offers a suspended caller no channel through which to receive a failure. The match is not clean across the board, and the paper says so: by its own table the coroutine executor expresses cancellation through destroy() on the handle, and its post can throw before it accepts the work. Does the symmetry hold where the paper claims it, or is the match overstated? Is its account of those differences right? And is the central claim convincing, that an infallible scheduling operation is the correct shape for a continuation rather than a defect to be fixed? 4. What is missing, and where is the argument weakest? What would undercut the claim? I am looking for counter-readings of P1525R0 and P2464R0, places where the work and continuation framings are not as clean a split as the paper draws, executor history it moves past, and consequences it does not follow through. Tell me what you went looking for and did not find. Thanks

9 19

Review request - P4003R3, "A Minimal Coroutine Execution Model"
by Vinnie Falco 28 Jun '26

28 Jun '26

Colleagues, 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. Please all read the same revision so the summary attaches cleanly to a published artifact: - **Paper under review - P4003R3:** https://wg21.link/P4003R3 - **Design companion - P4172 (rationale, alternatives, preemptive objections):** https://wg21.link/P4172 - **Umbrella - P4100 (the Network Endeavor):** https://wg21.link/P4100 - **Implementations:** Capy (https://github.com/cppalliance/capy) and Corosio (https://github.com/cppalliance/corosio) - **Self-contained demo:** https://godbolt.org/z/Wzrb7McrT What the paper proposes The paper asks LEWG to advance the *IoAwaitable* protocol as a standard coroutine execution model. It starts from the smallest possible use case, `co_await f();`, and observes that for this to work something must decide three things at the moment a coroutine suspends: 1. Who resumes it, and where (executor affinity). 2. Whether it should stop (stop token propagation). 3. Where its frame is allocated (frame allocator delivery). The protocol provides exactly those three things and nothing more. It is positioned as a companion to `std::execution` (P2300), not a replacement: each serves the domain where its design choices pay off. What I am asking you to evaluate Reviews here are informational. There is no verdict and no gate, so please do not feel you are voting the paper up or down. What I would most value is an honest read on four questions. **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? **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. **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? **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. Thanks

9 11