|
| 1 | +# Complement, Not Coexist |
| 2 | + |
| 3 | +## The Change |
| 4 | + |
| 5 | +Replace "coexist" framing with "complement" framing across all |
| 6 | +Network Endeavor papers. |
| 7 | + |
| 8 | +"Coexist" implies reluctant tolerance - two things sharing space |
| 9 | +because neither could displace the other. "Complement" says each |
| 10 | +model makes the other more valuable. The papers already demonstrate |
| 11 | +complementary behavior; the word should match. |
| 12 | + |
| 13 | +## The Canonical Line |
| 14 | + |
| 15 | +The Disclosure section of nearly every paper contains a variation of: |
| 16 | + |
| 17 | +> Coroutine-native I/O and `std::execution` address different |
| 18 | +> domains and should coexist in the C++ standard. |
| 19 | +
|
| 20 | +Replace with: |
| 21 | + |
| 22 | +> Coroutine-native I/O and `std::execution` are complementary. |
| 23 | +> Each serves the domain where its design choices pay off. |
| 24 | +
|
| 25 | +## Why "Complement" Is Correct |
| 26 | + |
| 27 | +The papers already make the complementary case: |
| 28 | + |
| 29 | +- The design fork (P4088R0 Section 10) shows two columns of |
| 30 | + strengths where neither is a subset of the other |
| 31 | +- The bridge papers (P4092R0, P4093R0) show the two models |
| 32 | + working together, not merely alongside |
| 33 | +- P4126R0 proposes one I/O implementation consumed by both |
| 34 | + models at zero allocation cost - partnership, not tolerance |
| 35 | +- P4003R1 already uses the word "companion" |
| 36 | +- P4014R1 Section 12 interleaves sender pipelines and coroutine |
| 37 | + tasks in the same system |
| 38 | +- `std::execution::task` is itself both a coroutine and a sender |
| 39 | + |
| 40 | +## Where "Complement" Applies and Where It Does Not |
| 41 | + |
| 42 | +"Complement" describes the relationship between the two *models* |
| 43 | +at the domain level: |
| 44 | + |
| 45 | +- Senders serve GPU dispatch, heterogeneous execution, |
| 46 | + compile-time work graphs |
| 47 | +- Coroutines serve byte-oriented I/O, type-erased streams, |
| 48 | + separate compilation, ABI stability |
| 49 | +- The bridges (P4092, P4093, P4126) connect them at the boundary |
| 50 | +- Each model makes the other more valuable |
| 51 | + |
| 52 | +"Complement" does NOT mean accepting `std::execution::task` as |
| 53 | +the coroutine side of the partnership. The papers document real |
| 54 | +structural costs when the sender model tries to own coroutines: |
| 55 | + |
| 56 | +- Environment parameter fragments task interoperability (P4089) |
| 57 | +- AS-EXCEPT-PTR converts routine error_code to exceptions |
| 58 | + (P4007, P4090) |
| 59 | +- No symmetric transfer under the sender protocol (P2583) |
| 60 | +- Allocator timing mismatch (P4007) |
| 61 | +- Compound I/O results do not fit the three-channel model |
| 62 | + without data loss (P4090, P4091) |
| 63 | + |
| 64 | +The coroutine-native task (`task<T>`, one parameter) is ours. |
| 65 | +The sender pipeline is theirs. The bridges connect them. Be |
| 66 | +generous about the models complementing each other. Hold firm |
| 67 | +on the documented costs when the sender model absorbs coroutines |
| 68 | +through `std::execution::task`. |
| 69 | + |
| 70 | +## Vocabulary |
| 71 | + |
| 72 | +Preferred words, in order of frequency: |
| 73 | + |
| 74 | +- **complement** / **complementary** - the default. The models |
| 75 | + complement each other |
| 76 | +- **companion(s)** - when the sentence needs a noun. "Both |
| 77 | + companions provide structured concurrency." "C++26 ships |
| 78 | + both companions." "Three companions - each contributing |
| 79 | + what the others cannot" |
| 80 | +- **contribute** - when describing what each model brings. |
| 81 | + "One contributes optimization visibility. The other |
| 82 | + contributes structural type erasure" |
| 83 | + |
| 84 | +## Kill List |
| 85 | + |
| 86 | +| Kill | Replace with | |
| 87 | +| :--- | :----------- | |
| 88 | +| coexist / coexistence | complement / complement each other | |
| 89 | +| domain split | complementary specializations | |
| 90 | +| domain-specific (execution models) | complementary (execution models) | |
| 91 | +| separation / the measure of the separation | (rewrite - bridges connect, they do not separate) | |
| 92 | +| each serving its domain | each contributing what the others cannot | |
| 93 | + |
| 94 | +## The Task Friction Pattern |
| 95 | + |
| 96 | +The models complement each other. `std::execution::task` |
| 97 | +trying to serve both models in one type does not. |
| 98 | + |
| 99 | +Serving both models in one type is where friction originates - |
| 100 | +two template parameters, sixteen open issues, constraints that |
| 101 | +neither model alone requires. The companion approach accepts |
| 102 | +the design fork: each model does what it does best, and bridges |
| 103 | +connect them at ~10-14 ns with zero allocations. |
| 104 | + |
| 105 | +**Narrative rule:** Do not lead with this observation. The |
| 106 | +paper goes about its business documenting coroutine strengths. |
| 107 | +The task friction surfaces when it arises naturally - typically |
| 108 | +in a Q&A or comparison section. The posture is incidental |
| 109 | +("and by the way"), not prosecutorial. |
| 110 | + |
| 111 | +## Instructions |
| 112 | + |
| 113 | +When editing a paper: |
| 114 | + |
| 115 | +1. Find every instance of "coexist" (including "coexistence", |
| 116 | + "should coexist", "can coexist") and every instance of |
| 117 | + "domain split" |
| 118 | +2. Replace with the complementary framing. Match the surrounding |
| 119 | + tone and sentence structure. Not every replacement is the |
| 120 | + canonical line - some are mid-paragraph and need to flow |
| 121 | + naturally. Use the Vocabulary and Kill List sections above |
| 122 | +3. Do not weaken the claim. "Complement" is stronger than |
| 123 | + "coexist", not softer. The two models are partners that |
| 124 | + complete each other's capabilities |
| 125 | +4. Do not change the meaning. The papers never argue that |
| 126 | + `std::execution` should be removed or modified. That stance |
| 127 | + is unchanged. The word is changing, not the position |
| 128 | +5. Do not soften documented findings about `std::execution::task`. |
| 129 | + The complement framing is about the models, not about |
| 130 | + accepting the sender task as equivalent to a coroutine-native |
| 131 | + task |
| 132 | +6. Let the task friction observation surface naturally when |
| 133 | + `task` comes up in context. Do not lead with it |
| 134 | +7. Preserve the ASCII-only rule (no Unicode, no em-dashes) |
0 commit comments