Review request - P4253R0, "Examining Six Observations on std::execution"
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_tok... 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
As with the other reviews, Networking is not my domain of expertise.
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.
For the purposes of this review I will assume that the citations match the source material. Under this assumption, the conclusions drawn from the citations seem fine; there do not seem to be an large logical leaps taken.
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?
Given my lack of experience I don't feel qualified to answer this question.
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?
I do not think the falsification criteria are the right ones. You've post-hoc drawn the falsification boundaries around the negative findings themselves; a test that cannot fail is not a test. At current it reads like a circular argument, which I expect was not the goal, so I would highly recommend rewording these.
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.
This paper seems to have a higher frequency of AI catchphrases than the previous ones (e.g., "No dynamic allocation. No shared ownership. No conditional eagerness."). Maybe whichever AI you're using thinks this is more convincing for comparisons? There also seemed to have more odd linguistic choices such as: "the raison d'etre thereof"; "germane to"; "Let us examine how each discharges the obligation thereby imposed". Are these technically correct? Yes. Does legalese in an informational standards paper read strangely? Also yes. I will say this paper does seem to be trending in the correct direction. It does seem to be more self-contained than the previous ones. Its length is not an impediment to understanding since it is still quite short even though it is ~2x the size of the previous paper under review. Matt
This is my review of P4253R0.
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.
The comparison between Asio's and Capy's sender bridge in section 5 isn't an argument towards what you try to state. You are comparing two bridges. Capy's bridge is simpler than Asio's. This is an argument against Asio's model, not towards std::execution invariants' fitness for I/O. I'm not convinced by Leahy's own claim on Asio's "abandonment". AFAIK no operation in Asio, or any of the libraries built on top of it, abandon operations as a form of completion. I'd call an operation that does this a bug. Maybe this was a thing before the introduction of per-operation cancellations? The only real case where abandonment could happen is stopping an io_context before it runs out of work. But then capy/corosio would suffer from the same problem, too. Partial success is correctly characterized. The removal of split() is correctly characterized. It doesn't add anything to the "senders' invariants may not be the right ones for I/O" because none of the arguments are related at all with I/O. It adds to the "senders are too complex" or "senders have undergone too many committee changes" arguments though. If that is the intent of the paper, please state it clearly. The when_all fix description is convoluted and should be simplified. Before the paper, when_all checked for cancellations before starting child operations, and hence would unconditionally add set_stopped_t() to the completion signatures, even when no children supported completion. Again, this has nothing to do with I/O, but adds to the other two arguments that I stated before. The language change is well characterized and adds to the paper's arguments.
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?
See above.
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?
I find this section as if it was written to help LLM reasoning rather than human consumption. I'll try my best analyzing it, even if I'm not its target audience. "A sender design that achieves zero per-operation allocation under type erasure for byte-oriented I/O, matching the coroutine model's structural property documented in Section 5." You haven't argued anything about allocations under type erasure in this paper, so I find this weird. "A channel mapping that preserves both the error code and the byte count without routing I/O errors through set_value, matching the coroutine model's compound result documented in Section 6." Correct. "A motivation for P3950R0 [7] that does not involve the sender channel model's interaction with coroutine promise types - that is, a reason the language restriction would need to be removed even if std::execution::task did not exist." Correct. "Evidence that split's eagerness, dynamic allocation, and shared ownership served a use case within the sender model's natural domain (i.e. compute dispatch and heterogeneous scheduling) that has no alternative expression via let_value and when_all." Sorry, I got lost here. I don't see the connection.
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.
Asio is constantly misspelled as "AIO". I found this strange and spent some time arguing with Claude whether this was the case, or I was missing something. I finally watched https://www.youtube.com/watch?v=S1FEuyD33yA, where the AI making the transcription constantly does the same mistake. This is grave enough for a reader to stop reading the paper. The paper also contains the words "thereof" and "thereby" multiple times, even outside Leahy's quotes. This is Leahy's style (which I personally find difficult to read). References to code should use commit hashes rather than branch names to be future-proof. Regards, Ruben.
Here's my review of P4253R0. First, what I think are some factual errors: - The paper calls P3950 something Leahy "proposes", but, by the paper's own date (post-Brno), it was well past a proposal: SG1 and EWG had cleared it, and CWG approved it as a Defect Report for C++29. This has two consequences: the abstract's "three of four adopted or forwarded" is really four (it has at least been forwarded), and the third falsification test is arguably already met (see below). - The execute snippet has `<typename F>` but the body uses `T`, so it would not compile. - "Five members" in par. 5 is wrong. `operation_state_base` has seven data members; the paper's own code block shows six; and it says `callback_` is "stored separately" but it is a member of the same struct, instead. The four questions: 1. Fair to Leahy? Yes. I just found one overstatement: Leahy wrote (PR #1501 comment, verbatim): "As a possible quality of life improvement `use_sender` should perhaps identify asynchronous operations which complete with `boost::system::error_code` as the first parameter to the completion handler and coalesce truthy completions to `set_error`, but perhaps that's best left as a separate algorithm to ensure that 'partial success' has its context fully preserved." This seems Leahy thinking out loud (note his "should perhaps" and "perhaps that's best left") but the paper (par. 6.1) says Leahy "prescribed" this. 2. Is the shared-boundary claim convincing? IIUC, this seems the weakest part. The whole argument rests on the word "boundary", yet the paper never defines what "the boundary where the sender model meets I/O" actually is. And the six observations do not share one cause: removing `split` is about a general compute-style algorithm, the `when_all` fix is about structured concurrency, and the `return_void` change is a general coroutine-promise defect the committee is fixing for all promise types; none of these seems specific to I/O. A real common thread does exist, but it is narrower and is a property of the model rather than of I/O: the sender model ends the operation state's life at the completion signal and routes results through fixed, typed channels, so there is nowhere to keep state or data that does not fit a channel - which is what genuinely unites observations 1, 3, and the par. 6 byte-count problem (the paper half-sees this in par. 2's "one-directional" operation-state stack). I would either narrow the claim to that property or broaden it to "the model's invariants cost more when the workload does not fit them" (which par. 12 already hints at), and drop the single, undefined I/O boundary. 3. Are the falsification tests right? Mostly, but: - As said above, test 3 (a reason to remove the `return_void` restriction even without `std::execution::task`) is arguably already met, because the committee is fixing it as a general defect for all promise types: CWG approved it as a Defect Report, and SG1 called the motivation "compelling for maintenance of promise types". - The bolded par. 6 claim "no mapping preserves both values" seems too strong: `set_error` can carry one compound value (a struct holding the error code and the byte count), which keeps both without using `set_value`. So the accurate claim seems to be the one par 6.1 already makes: no mapping preserves both *and* keeps the channels clean. 4. Did AI affect my read? Yes. I checked everything checkable :-). -- Gennaro Prota <https://prota.dev>
Unfortunately, both library in general and std::execution in particular are out of my area of expertise, and it doesn't contain any Library wording that I can try to apply my Core expertise to. On 03/07/2026 17:51, Mungo via Paper-reviews wrote:
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_tok... 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 _______________________________________________ Paper-reviews mailing list -- paper-reviews@lists.wg21.org To unsubscribe send an email to paper-reviews-leave@lists.wg21.org https://lists.wg21.org/mailman3/lists/paper-reviews.lists.wg21.org/ Archived at: https://lists.wg21.org/archives/list/paper-reviews@lists.wg21.org/message/A4...
participants (7)
-
Andrzej Krzemieński -
Gennaro Prota -
Matt Borland -
Mungo -
Ruben Perez -
Vinnie Falco -
Vlad Serebrennikov