Hi folks,

Just in time for Wednesday, R2 is now available at
https://isocpp.org/files/papers/P4223R2.html. It changes nothing in the
design or the proposed wording; it only brings the implementation section
up to date with stdexec, which now matches R1’s wording. The sections I
pointed to earlier (12.2 for SG14’s questions, then 9, 8.2, 6.4–6.5, 7.2
and the appendix) are unchanged, so either revision works for Wednesday.

Looking forward to our discussion,
Ian

On Fri, Oct 23, 2026 at 9:06 AM Ian Petersen <ispeters_at_[hidden]> wrote:

> Thanks, Michael, both for raising the cost question in Brno and for making
> room for this in an F2F month. Following up on what I offered there, I’m
> glad SG14 will look at it.
>
> The paper is long, and most of it isn’t aimed at SG14. The best entry
> point is §12.2, “Feedback from SG14”
> <https://isocpp.org/files/papers/P4223R1.html#feedback-from-sg14>, which
> states the three questions Michael listed and names the section that argues
> each one:
>
>
> 1. Whether connect may throw: §9, “The Exception Contract of connect”
> <https://isocpp.org/files/papers/P4223R1.html#the-exception-contract-of-connect>,
> especially §9.2 (the rule)
> <https://isocpp.org/files/papers/P4223R1.html#the-rule> and §9.3 (who
> chooses the failure policy)
> <https://isocpp.org/files/papers/P4223R1.html#choosing-a-failure-policy>
> .
> 2. Who chooses what happens when a frame can’t be allocated: also §9.3
> <https://isocpp.org/files/papers/P4223R1.html#choosing-a-failure-policy>,
> with §8.2 (“What the Wording Guarantees”)
> <https://isocpp.org/files/papers/P4223R1.html#what-the-wording-guarantees>
> for what the wording fixes and what it leaves to implementations.
> 3. What each operation costs at scale: the conclusion, §6.5
> <https://isocpp.org/files/papers/P4223R1.html#conclusion>, has the
> numbers for the reference implementation. Its operation state carries a
> 64-byte inline buffer that holds operation states of up to 56 bytes and
> goes unused whenever the frame is larger, as the paper’s example frame is.
> A hundred thousand outstanding operations of that kind leave 6.4 MB of
> buffers unused. The wording permits such a buffer but doesn’t require one;
> the question for SG14 is whether that’s the right place to leave it. Section
> 13.2 <https://isocpp.org/files/papers/P4223R1.html#beyond-the-wording>
> lists everything else the implementation does beyond the wording.
>
>
> Beyond those, the sections most relevant to SG14 are §6.4 (“Analysis”)
> <https://isocpp.org/files/papers/P4223R1.html#analysis>, where the paper
> engages the cost arguments in P4088R1 <https://wg21.link/p4088r1>—in
> particular §6.4.1
> <https://isocpp.org/files/papers/P4223R1.html#the-activation-frame-is-the-boundarys-cost>
> on its “design fork” (§10)
> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p4088r1.pdf#page=20>
> and §6.4.2
> <https://isocpp.org/files/papers/P4223R1.html#fixing-the-frames-size> on
> fixed-size buffers—and §7.2 (“Completion Signatures”)
> <https://isocpp.org/files/papers/P4223R1.html#completion-signatures>,
> which argues that partial success and error codes don’t need exceptions or
> a merged return value. The appendix
> <https://isocpp.org/files/papers/P4223R1.html#appendix-an-erased-stream-built-on-senders>
> builds P4088R1 §7.4 <https://wg21.link/p4088r1#page=9>’s erased read
> stream on senders. Those sections, §8.2, §9 and §12.2 together are roughly
> a quarter of the paper.
>
> The reference implementation is exec::function
> <https://github.com/NVIDIA/stdexec/blob/main/include/exec/function.hpp>
> on stdexec main (NVIDIA/stdexec#2321
> <https://github.com/NVIDIA/stdexec/pull/2321>, merged), for anyone who
> would rather measure than take the paper’s figures.
>
> I’ll be at the meeting on the 11th and can give a short framing of the
> three questions rather than a full presentation, unless Michael wants more;
> let me know how much time you’d like to give it. Since the 11th is before
> Búzios, I’ll relay whatever SG14 says to SG1 when it reviews R1 there.
>
> Thanks,
> Ian
>
> On Fri, Oct 23, 2026 at 7:45 AM Michael Wong via SG14 <
> sg14_at_[hidden]> wrote:
>
>> At Brno I was at SG1's review of P4223R0 and asked what
>> std::execution::function costs per operation at scale, and Ian Petersen,
>> the author I offered to bring the paper to SG14. R1 is now in the
>> pre-Búzios mailing, with SG14 added to its audience alongside SG1 and LEWG.
>> Thanks to Ian, he has published his design response in todays mailing and
>> wants to ask SG14 for its opinion:
>> https://isocpp.org/files/papers/P4223R1.html. Feel free to share.
>>
>> R1 asks SG14 for feedback on three things: whether connect may throw,
>> who chooses what happens when an operation's frame can't be allocated, and
>> what each operation costs at scale, including the inline buffer the
>> reference implementation uses.
>>
>>
>> As such even though I don't normally hold SG14 meeting in the month where
>> we have a F2F, I feel this issue is important enough that we hold an SG14
>> meeting on Wednesday, Nov 11, 2pm ET for SG14 to give its response to this
>> paper.
>> _______________________________________________
>> SG14 mailing list
>> SG14_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>>
>