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
>