P3175 R2 Reconsidering the `std::execution::on` algorithm

[wg21bot]

P3175R0 Reconsidering the std::execution::on algorithm (Eric Niebler)

[inbal2l]

2024-04-16 Library Evolution Telecon

P3175R0: Reconsidering the std::execution::on algorithm

2024-04-16 Library Evolution Telecon Minutes

Champion: Eric Niebler Chair: Fabio Fracassi Minute Taker: Ben Craig

Summary

POLL: Rename std::execution::on to std::execution::start_on (P3175R0 Change 1)

SF	F	N	A	SA
5	7	1	1	0

Attendance: 18 Author's Position: SF Outcome: Consensus in Favor

POLL: Rename std::execution::transfer to std::execution::continue_on (P3175R0 Change 2)

SF	F	N	A	SA
4	7	0	3	0

Attendance: 18 Author's Position: SF Outcome: Consensus in favor

POLL: Add a new "on" algorithm with "scoped start_on semantic" (front) (P3175R0 Change 3)

SF	F	N	A	SA
3	9	2	0	0

Attendance: 18 Author's Position: SF Outcome: Strong consensus in favor

POLL: Add a new "on" algorithm with "scoped continue_on semantic" (middle) (P3175R0 Change 7)

SF	F	N	A	SA
4	7	3	0	0

Attendance: 19 Author's Position: SF Outcome: Strong consensus in favor

POLL: Rename read to read_env (part of P3175R0 Change 4)

SF	F	N	A	SA
12	2	0	0	0

Attendance: 19 Author's Position: SF Outcome: Strong consensus in favor

POLL: POLL: Add a new adaptor write_env (part of P3175R0 Change 4)

SF	F	N	A	SA
2	7	3	0	1

Attendance: 19 Author's Position: SF Outcome: Consensus in favor

POLL: POLL: Add a new adaptor unstoppable (P3175R0 Change 5)

SF	F	N	A	SA
1	6	5	0	1

Attendance: 19 Author's Position: WF Outcome: Weak consensus in favor

POLL: Add a new algorithm finally and specify the default schedule_from in terms of it (P3175R0 Change 6)

SF	F	N	A	SA
3	5	4	0	1

Attendance: 19 Author's Position: SF Outcome: Weak consensus in favor

SA: unconvinced that the majority of the people in the room understood the motivation or what we were voting on.

Paper forwarding checklist:

1. Why should this utility go into the standard library? improve API of an existing facility
2. Examples? yes
3. Discussion of prior art? yes
4. Implementation experience? yes
5. Usage experience? yes
6. Deployment experience? no
7. Performance considerations? n/a
8. Changes Library Evolution previously requested? n/a
9. Support in "std::format" and "hash" (if required)? n/a
10. Feature test macro? n/a
11. Freestanding? n/a
12. Wording? yes

Next Steps

The paper was reviewed and we approved: ::on, ::start_on, ::transfer, ::continue_on, ::on (+ scoped start_on semantic), ::on (+ scoped continue_on semantic), rename read to read_env.

In addition, we approved: adding adaptors: write_env, unstoppable, add a new algorithm finally and specifying the default schedule_from in its terms.

It was brought up in the reflector that the second list of items did not have enough discussion, we will briefly review it during the next LEWG meeting, before reviewing the wording and taking a forwarding poll.

[inbal2l]

2024-05-14 Library Evolution Telecon

P3175R0: Reconsidering the std::execution::on algorithm

2024-05-14 Library Evolution Telecon Minutes

Champion: Eric Niebler Chair: Fabio Fracassi Minute Taker: Mark Hoemmen

Summary

Open questions for next meeting:

• Motivational examples for write_env, unstoppable, and finally.
• Should finally be unstoppable by default?
• Should finally have the mechanism/responsibility to check whether the "cleanup" work needs to be done
• Should finally be called something along the lines always_do, or upon_completion (needs proper example)

We looked at examples for write_env, unstoppable, finally. Somewhat in depth explanation of how environments work in P2300 (to better understand the usage of write_env).

Sender vs Receiver environments finally is kind of a async destructor. A core language facility for a real async destructor would be useful.

Next Steps

Explore a higher-level algorithm like try_finally that is on the screen. Split unstoppable and finally from the paper and move them into its own paper. (R1)

[inbal2l]

2024-05-21 Library Evolution Telecon

P3175R1: Reconsidering the std::execution::on algorithm

2024-05-21 Library Evolution Telecon Minutes

Champion: Eric Niebler Chair: Inbal Levi Minute Taker: Eddi Nolan

Summary

We gave indication to the author on the best way to customize "scheduler env" into the "on" algorithm for a future paper.

POLL: Knowing what we know now, we support the options (voting to multiple options is possible):

If there’s no scheduler for “on”:

• (Option 1 in the paper): Any algorithm that eagerly connects a sender should take an environment as an optional extra argument. That way, users have a way to tell the algorithm what the current scheduler is. They can also pass additional information like allocators and stop tokens.
• (Option 4 in the paper): Those algorithms can set a hidden, non-forwarding “root” query in the environment. The on algorithm can test for this query and, if found, perform a no-op transition when it completes. This has the advantage of not setting a “current” scheduler, which could interfere with the behavior of nested senders.
• (Option 5, discussed in the room): Add “write_env” and use it as in: start_detached(write_env(on(sched,sndr), with(get_scheduler, pool)));

Option 1	Option 4	Option 5
13	5	11

Attendance: 19 Outcome: Options 1 and 5 are endorsed by LEWG

POLL: Make the “on” algorithm non-customizable, and publish P3175R2 (wording to be reviewed by LEWG) targeting C++26 as B2.

SF	F	N	A	SA
7	4	1	0	0

Attendance: 17 # of Authors: 1 Author Position: SF Outcome: Strong consensus in favor N: I support the motion of this paper. I voted neutral because I feel things started being messed up with naming for start_on.

Next Steps

We finalized the design questions. The author will publish an R2 with the wording that reflects the removal of customization of the "on" algorithm.

The room has agreed that once the wording is reviewed (during an early session in St. Louis), we will take a forwarding poll - without electronic polling - so that the paper will make it on time for LWG in St. Louis.

[wg21bot]

P3175R1 Reconsidering the std::execution::on algorithm (Eric Niebler)

[wg21bot]

P3175R2 Reconsidering the std::execution::on algorithm (Eric Niebler)

[ben-craig]

P3175R2: Reconsidering the std::execution::on algorithm

P3175R2: Reconsidering the std::execution::on algorithm

2024-06-24 Library Evolution St. Louis Minutes

Champion: Eric Niebler

Chair: Ben Craig

Minute Taker: Khalil Estell

Summary

POLL: Make execution::on's customization consistent with the other algorithm customizations, instead of making it intentionally difficult to customize.

Attendance: 21 in person + 14 remote

Outcome: No objection to unanimous consent

POLL: Change start_on and continue_on to starts_on and continues_on

SF	WF	N	WA	SA
3	7	11	1	0

Attendance: 20

# of Authors: 1

Author Position: N

Outcome: Weak consensus

Comments: WA: prefer active verb names

POLL: Make execution::on's customization consistent with the other algorithms, rename start_on and continue_on to starts_on and continues_on, address the wording concerns captured in the minutes, and then send a new revision (R3) of P3175 (Reconsidering the std::execution::on algorithm) to LWG for C++26 classified as B1 (key features), without an electronic poll

SF	WF	N	WA	SA
4	7	1	0	0

Attendance: 16 in person + 4 remote = 20

# of Authors: 1

Author Position: SF

Outcome: Consensus in favor

Next Steps

Update the paper, publish an R3, and take the resulting merge with P2300 to LWG

[inbal2l]

P3174R3 Reconsidering the std::execution::on algorithm (Eric Niebler)

(forwarded to LWG for C++26)