В письме от четверг, 18 июня 2026 г. 21:17:00 MSK пользователь Vinnie Falco написал:
**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?
It does to me. But I'm not sure this is because of the paper, and because of my prior exposure to the things it describes.
**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.
Use of AI did not affect my perception, but, consider this line in section 2.
The left column is small. The right column is not. Small protocol, big rewards. It earns its keep.
This is written as an artistic advertisement (something that LLMs often do). I don't think this style is warranted in a standards proposal.
**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.
I feel like the split into this paper and P4172 is detrimental. This paper is not a wording proposal, supposedly it needs to convince me that the design it outlines is the necessary minimum. But most of the explanation (design rationale, comments on alternative approaches, etc.) is in another paper.