- Paper-reviews - lists.wg21.org

Review request - P4253R0, "Examining Six Observations on std::execution"
by Mungo 09 Jul '26

09 Jul '26

Colleagues, I am requesting a formal review of P4253R0, "Examining Six Observations on std::execution." The paper examines the published work of one practitioner and asks what his observations share. It asks for nothing. Please all read the same revision, so the summary attaches cleanly to a single document: - Paper under review - P4253R0: https://isocpp.org/files/papers/P4253R0.pdf - The practitioner's papers it examines: P3373R2 (operation state lifetimes): https://wg21.link/P3373R2 P3682R0 (remove split): https://wg21.link/P3682R0 P3887R1 (when_all Ronseal): https://wg21.link/P3887R1 P3950R0 (return_value and return_void): https://wg21.link/P3950R0 - The production code it examines: completion_token.hpp in NVIDIA/stdexec: https://github.com/NVIDIA/stdexec/blob/main/include/exec/asio/completion_to… use_sender.hpp in NVIDIA/stdexec: https://github.com/NVIDIA/stdexec/blob/main/include/exec/asio/use_sender.hpp PR #1501 review comments: https://github.com/NVIDIA/stdexec/pull/1501 - The CppCon talk it draws from: https://www.youtube.com/watch?v=S1FEuyD33yA What the paper argues Robert Leahy has authored production code in NVIDIA's stdexec, four WG21 papers (three adopted or forwarded by the committee), and a detailed specification of AIO-to-sender bridge invariants. The paper traces six observations from Leahy's published work: 1. A bridge requiring a recursive mutex, an intrusive linked list, and abandonment detection, where the coroutine equivalent requires a context structure and a callback. 2. A channel mapping that discards the byte count on the error path because the three-channel model affords no mapping that preserves both the error code and the remaining arguments. 3. A recommendation that partial success should have its context fully preserved, followed by an implementation that cannot preserve it. 4. An algorithm (split) removed for dynamic allocation, shared ownership, and conditional eagerness. 5. An algorithm (when_all) corrected for injecting stopped completions that no child sends. 6. A language change needed by std::execution::task and by no other task type in a decade of coroutine libraries. The paper argues these six observations share one property: they each arise at the boundary where the sender model meets I/O. It does not argue that the sender model is wrong. It asks whether the invariants the model maintains are the right ones for that domain. Reviews here are informational. There is no verdict and no gate, so please do not feel you are voting the paper up or down. Here are some ideas for questions to guide your evaluation, but your review is welcome to, and in fact should, make observations on any aspects of the paper that you deem appropriate. 1. Is the characterisation of Leahy's work fair? The paper claims to examine published code, papers, and talks, and to draw conclusions from them. Is Leahy's work represented accurately? Are any observations taken out of context, overstated, or missing a qualification that would change their weight? If you are familiar with any of the source material, please say where the paper gets it right and where it does not. 2. Is the shared-boundary claim convincing? The central argument is that six observations, each independently addressable, share one cause: they sit at the boundary where the sender model meets I/O. Could the six be explained by other causes? Are there observations from Leahy's work (or from others working in the same space) that the paper omits and that would weaken or strengthen the claim? 3. Are the falsification criteria in Section 11 the right ones? The paper lists four conditions that would discharge the observations. Are those conditions correctly stated? Are there other ways to explain the observations that the paper does not consider? 4. Did the use of AI affect your perception? The papers in this series, and the review programme 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. Thanks

7 6

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