Thank you for giving us this opportunity to review this work. As previously discussed, I am: - not a coroutine expert - not a networking expert - but I know how to write papers and pedagogical material Disclosure: I am compensated by the C++ Alliance, which authored this paper. All paragraphs written in this review aim at showcasing pedagogy/structure rather than making technical points. Overall this work is rather impressive and interesting, but the paper's current form dilutes the message to the point where reviewers had to question its usefulness. This is a shame because I believe the message is interesting and important. The work accomplished is impressive and important: it draws on a decade of technical debates to identify a pattern that previous discussions missed, informing future design discussions. The core information being surfaced by this work exists but is diluted across papers, making it likely to be rediscovered multiple times (or not at all) and causing progress in standardization to be more erratic. Making this explicit in a single paper has merit. That being said, in its current shape, the paper asks reviewers and readers to perform not a review, but a meta-analysis, which is not acceptable. That is, to understand and guarantee the paper's claims, one has to read the paper trail: | Document | words | read at 100 wpm | |---|---|---| | P4286R0 under review | ~2,000 | ~20 min | | P4094R1 | ~8,000 | ~80 min | | P4095R1 | ~4,000 | ~40 min | | P4096R1 | ~4,500 | ~45 min | | P3552R3 | ~19,000 | ~190 min | | P3941R4 | ~8,500 | ~85 min | | P4003R3 | ~5,500 | ~55 min | | P0113R0| ~20,000 | ~200 min | | P1525R0 | ~4,000 | ~40 min | | P0443R14 | ~16,000 | ~160 min | | P2464R0 | ~3,500 | ~35 min | | **Total (10 papers)** | **~93,000** | **~15.5 h** | This poses an ethical problem and a strategic problem. The ethical problem emerges when unpaid reviewers try to review/read this paper: they are likely to skim through or not complete the review. This biases the review process towards paid work and C++ Alliance affiliation. It's better than nothing but the bias is worth understanding and its consequences on the C++ open source communities must be also appreciated (we want community volunteers to jump in such process, not jump out). The strategic problem is the most critical: the purpose of this paper is to get reviewed by a committee that will likely 1) not have the sufficient background to assess the paper's merit based on pre-existing knowledge of the field, and 2) not have the time to build the required knowledge. IMO the solution to these two issues is, as mentioned by previous reviewers, to make the paper self-contained. I hope to present some ideas below on how to achieve this better. ## Abstract The first place to begin with is, like the previous paper, the abstract. To increase the chances of being read, understood and accepted, any abstract must follow the same pedagogical pattern. Following the structure from the previous review, it could look something like this (again, I'm no expert here, so forgive technical mistakes):
(broadest context) Designs are governed by invariants that often go unstated as principles. When an invariant is left implicit, the question it governs can be answered one way in one place and the opposite way in another, and the contradiction goes unnoticed because there is no stated principle to check either answer against. This paper surfaces one such invariant in C++'s asynchronous execution model. Asynchronous C++ is built on executors: the objects that decide where a suspended computation resumes, whether it should stop, and how its result is delivered. A recurring design question is whether the operation that schedules a resumption should itself be able to report a failure.
(narrowing) The committee has answered this differently at different times. In 2021 it set aside the Networking TS partly because its executors had no way to report such a failure, and stated this as a design deficiency. In 2026, std::execution::task requires (through affine_on, P3941R4) that the scheduler driving it be infallible, stating as a requirement it may not report a failure at all. The same property is, six years apart, a defect and a requirement.
(narrowing to the method) This paper asks whether that is a contradiction or a consequence. It examines the question across three executor designs spanning a decade, using one distinction: whether the thing handed to the executor is a task to run, with the caller still alive and able to act on a failure; or a handle that resumes a caller which has already suspended and is therefore unable to act on one.
(specific contribution, evidence, take-home) We show that the three designs converge on the same shape: a scheduling step that returns no value and reports no failure. The paper argues this follows from the caller's state, not from any one design, concedes where the correspondence is inexact, and draws a forward conclusion: an infallible scheduling step is the correct form for resuming a suspended caller, which bears on how a coroutine-native execution model (P4003R3) should sit alongside std::execution.
1) Disclosure
1) Disclosure
## Abstraction Layering Overall the abstraction layering is a mess. You want papers layered by abstraction level, similar to how a library is structured: present high level concepts first for easy entry, followed by progressive dives into details. You should isolate concepts at the same abstraction level in similar paragraphs, much like organizing details in a namespace within a library. The abstract, introduction, and transition paragraphs between sections MUST document this structure so the reader understands why they need to understand the details. ## ToC The clearest signal for information layering is the table of contents, but currently it reads like the beats of a blog post: 2) The Diagnosis 3) The Framing 4) The Return 5) The Coroutine Executor 6) The Symmetry 7) A Possible Objection 8) The Shape There is no intelligible message in the ToC, and it's degrading both human and automated capacity to extract high-level signals from the paper's body. They do not signal content or progress, they carry rhetorical/political arcs rather than structure: "The Diagnosis" frames the committee as terminally-ill patients, "The Symmetry" and "The Shape" frame the paper as a revelation. Although amusing to me (I get the intention), this may be felt negatively by others, which endangers the paper for no gain. In an automated pipeline for paper analysis, the first thing you will want to do is extract ToCs for mapping context to pages numbers, which is currently pessimized. So in any dimension considered, this is not an efficient way to convey your message. I suggest something like: 2) Background: the error-channel deficiency (P1525R0, P2464R0) 3) Two framings of execute(F&&) 4) The infallibility requirement (P3941R4) 5) The coroutine executor (P4003R3) 6) Comparison: a shared shape across three executors 7) Anticipated objection: incapability versus selective constraint 8) Conclusion: the shape follows from the caller's state ## Introducing and justifying the paper's structure This ToC will allow you to layer concepts and definitions in a more efficient manner in e.g. an Introduction or Method (keep the abstract, it answers a different problem). You could write something like:
The paper builds its case step by step. It first establishes the premise that the absent error channel was treated as a deficiency (Section 2), then introduces the distinction the whole analysis rests on, between scheduling work and scheduling a continuation (Section 3). With that definition lens in place, it turns to the other half of the apparent contradiction, the 2026 requirement that such schedulers be infallible (Section 4), and adds a third case that reaches the same constraint with no reference to the committee's history, the coroutine executor (Section 5). With three instances in hand, it compares them and draws out their common shape (Section 6), answers the strongest objection to that reading (Section 7), and closes by locating the cause of that shape in the caller's state rather than in any one design (Section 8)
## Make your definitions clear and explicit
Under the work framing ...
Under the continuation framing ...
This is confusing, as it's hard to understand that you are actually defining terms that are quintessential to the paper. I suggest:
The signature void execute(F&& f) admits two interpretations, here termed the **work framing** and the **continuation framing**. The two differ in what the callable `f` denotes and, consequently, in the state of the caller.
Under the work framing, f denotes a unit of work that the executor runs. The caller has delegated that work and continues to execute; it remains live and expects to observe the outcome. The absence of an error channel is then a defect, since a failure has no path back to a caller that is still running.
Under the continuation framing, f denotes a resumption handle: the mechanism by which a caller that has already suspended, or returned, is later resumed. The work is performed elsewhere, typically by the operating system, and the suspended caller is resumed with the result once it is available. The absence of an error channel is then not a defect, since no caller remains to receive one.
Whether the absent channel constitutes a defect or the correct form therefore depends on the framing, and in particular on whether the caller is running or suspended.
After this is stated, you can then feel free to drop particular paper references and quotes and more details, now that the reader has a high-level conceptual net where to land those bits of knowledge. ## The conclusion does not land well
The committee rediscovered that continuations need a continuation-framed executor.
This is almost circular and fails to provide a clear takeaway for the reader. If anything it weakens the paper's conclusion and diminishes its chances of being understood. Consider instead closing with something that provides value to the reader:
To decide whether a missing error channel is a defect or the correct form, the criterion is the caller's state, not which model of asynchrony is used (sender/receiver, coroutine, completion token): a step that resumes an already-suspended caller rightly has no error channel (in any model where it occurs) because there is no running caller left to receive one. Stating this once, as a model-independent principle, would spare C++ from re-deriving it design by design. Among those models, coroutines are where this is not one option but the default, since every co_await suspends the caller, so a coroutine-native execution vocabulary could be its most natural home. P4003R3 develops one such model.
## Other
This paper asks for nothing.
I am uncomfortable with this line. A paper always asks for something, and in this specific case it asks for something considerable: that the reader adopts a particular framing of the executor history and accepts an interpretation under which an established constraint is recast as correct, and maybe even read your other paper p4003R3. Maybe you meant "This paper does not ask for direct committee action". ## Did AI impact your perception Since I am being asked, I will answer truthfully. I do believe (personal interpretation) that authors have passed the threshold of AI usefulness in the writing process. There is a point where edition must become manual, paragraph by paragraph, sentence by sentence, word by word, in order to reconstruct a knowledge landscape that can be efficiently walked by a human reader. Humans at the end are reading the paper for understanding, so humans must construct this understanding. Correct but incorrectly structured information is not knowledge, to a reader it will be interepreted as noise. Knowledge is what you get when you arrange the information so that another human can absorb it: that rearranging is an act of intuition about what the reader already holds, what they maybe forgot, what they need next, and in what order. This is precisely what AI is poor at. I don't believe the problem of human pedagogy (i.e. making complex and diluted information intuitive and accessible) is solved by more tokens or more tooling. It is solved by a human doing that work. This connects to the ethical point made earlier. When the manual, intuitive reconstruction is not done (or not enough), it does not disappear: it is transferred to the reader and reviewers, who must rebuild the knowledge the paper should have presented. That goes uncredited, and unpaid for those not paid to do it. The issue is not that AI was used. It is that, in its current form, the final human pass that turns aggregated data into something a reader can learn from does not come through, even where it may in fact have been done. That is not only an ethical concern but a strategic one: you want reviewers, readers, and committee members to come away with the intuition that the work was carefully and manually crafted, and the current form does not convey that. ## Overall assessment Impressive underlying work, undercut by a form that asks the reader to reconstruct it from a very large paper trail. I enjoyed understanding the problem but the irony is that the paper did not really help me do so - I had to reconstruct my own understanding (probably off and/or incomplete), which is not the state you want any paper to be in. If made self-contained (with a pedagogical abstract, a descriptive ToC presented in a dedicated paragraph, concepts defined before they are used, and references used to support rather than carry the rationale), this could become a paper a committee can actually act on and that a reader can enjoy reading, and the message deserves that effort. Thank you again for the opportunity, I'm keen to see where it goes. Best wishes, Arnaud Becheler