4255 first pass

[lorihughes]

First pass edits through part of section 5, then I stopped because this paper needs a thorough rewrite. The paper contains repeated sentence fragments, nonsensical phrasing, vague pronoun/antecedent situations, etc.

Author comments from Claude:

Editorial notes for the author — P4255R0

Note: the editing pass covered the abstract through §5 step 4 and stopped. The first two notes concern the paper as a whole and should be settled before further line editing.

• A sentence-level audit is needed, and it outranks the length problem. The most common line-level defect is verbless fragments used for emphasis — six instances in four sections, recurring throughout the unedited remainder. That much is mechanical: one pass, one rule, every emphatic beat becomes a clause with a subject and a verb. The more consequential finding is what sat underneath several of them.

  • §5, on the inline_scheduler sender: "This sender is the standard's own facility for inline completion, not a hand-rolled type, but the facility P3552R3 provides for exactly this case." The "but" contrasts nothing — the clause after it restates the clause before it. And the sentence appears to attribute inline_scheduler to P3552R3, when the facility comes from std::execution and what P3552R3 contributes is the await_transform bypass. The paper's own §5 step 1 describes it correctly.
  • §4, the affordances sentence: the number of list items and the boundaries between them cannot be recovered from the punctuation. Two or three readings are consistent with the text, and they say different things about how the paper's central comparison was configured.
  • §3: "the algorithm's object code does not know whether the stream is synchronous" attributes knowledge to a compiled artifact.
  • The audit should cover every sentence claiming which document provides which facility, which clause specifies which behavior, and which paper introduced which mechanism. Three such problems appeared in five sections, so the base rate is not negligible.
  • A misattribution in a paper arguing that the sender model handles a case incorrectly costs more than its size suggests. A reader who checks one such sentence and finds it does not hold has reason to check the numbered traces — which are the paper's strongest material and do not deserve that doubt.
  • Not in question: the §5 and §6 step traces, the §7 table, the §11.5 benchmark, §4's recognition of three sender achievements, and §13's falsification criteria. The traces are checkable step by step against cited clauses. The benchmark reports its own limitation unprompted. §12's concession on as_awaitable is stated plainly and narrowed correctly.

• The paper makes its case by §7 and continues for another 4,000 words. Sections 1 through 7 are the argument: seven numbered steps for the sender path against three for the awaitable path, each cited to a clause, with §7's table setting the per-write costs side by side. A reader who stops at §7 has the finding, the evidence, and the means to check it.

  • Sections 9, 10, 12, and 14 restate that result rather than extending it. The seven-step sequence is described again in §9, §10, §11.1, §11.2, §12, and §14. Two phrases recur verbatim: the synchronous-case list ("buffered writes, cached reads, DNS cache hits, and in-memory operations") in §12 and §14, and the protocol list ("TLS, HTTP, WebSocket, SMTP, and DNS resolution") in §10 and §12. §3.3 confines the full statement of the finding to the abstract and conclusion; it currently appears in roughly eight places.
  • §12 specifically states and answers thirteen objections, all supplied by the paper, all resolving in the paper's favor. §5 requires objections in their strongest form, and thirteen is not stronger than four. Several are answered in two sentences each, which suggests they were not serious challenges. The ones carrying real weight and worth expanding: the as_awaitable customization point, the unshipped-P4126R2 dependency, the claim that step counts are not runtime costs, and possibly the optimizer objection.
  • §11 occupies roughly a third of the document and is the one part arguing from construction rather than from the record. §11.6 already states the four mechanisms and their mapping onto the awaitable's three members; the preceding subsections could be compressed toward that.
  • Cutting §12 to four objections and removing the restatements from §9, §10, and §14 would eliminate a substantial share of the passages that would otherwise need the fragment fix.

• §3, the emphasized closing line — remove the emphasis or cut the sentence. Currently The algorithm was compiled once. The execution model was chosen by the linker. (changed from bold to italic in this pass, which reduces weight without addressing the issue).

  • §2: the reader who draws a conclusion owns it. §5: the paper stops when the evidence stops.
  • The two paragraphs above demonstrate the point completely — one algorithm, two object files, two execution models, no recompilation. The restatement tells the reader what they just worked out.
  • §9 wants each section to close with a local conclusion, and this qualifies in content. But a local conclusion is an ordinary sentence; emphasis makes it a pull-quote. The paper uses the device at least twice, here and at "This is await_ready." in §10, and in both places the surrounding text has already established the point.

• §4, the affordances sentence — the list structure cannot be recovered from the punctuation. Currently: "The comparison that follows grants senders every affordance: inline_scheduler::schedule() as the sender - the standard's own facility for inline completion^[5] - synchronous completion inside start, and the minimal completion_signatures<set_value_t()>."

  • "The standard's own facility for inline completion" may be a gloss on the first item or a second item in its own right. The dashes were the only thing distinguishing the readings, and house style does not use them.
  • The items are bare noun phrases with no verb, so nothing states what is granted in each case.
  • This was left unedited deliberately: guessing at the intent would risk stating something the author did not mean, in the sentence that establishes the terms of the paper's central comparison.
  • The rewrite needs each grant stated with a verb and the boundaries marked by a vertical list or semicolons.
  • Related: "affordance" appears here and in the abstract. It is design-theory vocabulary rather than standard C++ usage; "advantage" is plainer for an international readership. The abstract has been changed accordingly and this instance would match.

• §5, the inline_scheduler sentence — unresolved. Detailed in the first note above. Three questions need answering before it can be rewritten: whether the sentence stays at all, which document provides inline_scheduler, and what the "but" is meant to contrast. The preceding paragraph already establishes that start calls set_value immediately, and §4 already states that the comparison grants senders the standard's own facility — so the sentence may be redundant even once corrected.

[MungoG]

Given 4255 has been updated, I'll cherry pick these changes into the doc (easier than just merging the PR)

[MungoG]

I pulled the relevant parts of this PR into the file manually.