great, another execution paper. at this rate we'll have async hello world standardized by C++32

The name affine_on isn't great. It may be worth giving the algorithm a better name.

That's Section 3.7. In its entirety. The full analysis. A 15-page paper rewriting the algorithm's parameters, constraints, and semantics, and the naming section is two sentences.

The elephant in the room is parallel_scheduler.

The paper requires infallible schedulers for affine_on, then says:

It seems unlikely that all schedulers can be constrained to be infallible.

And specifically about parallel_scheduler:

It seems unlikely that this interface can be constrained to make it infallible.

So we're standardizing task with scheduler affinity baked in, and one of the four standard schedulers can't participate. The paper acknowledges this but offers "the user can adapt the scheduler" without providing any such adapter in the standard library. The only adaptation strategies listed are (1) call std::terminate on failure, or (2) silently break affinity and hope nobody notices.

I understand why infallibility is the right constraint - if scheduling fails you genuinely cannot guarantee resumption on the right execution agent. But the practical consequence is that task + parallel_scheduler is a compile error. That seems like something LEWG should discuss explicitly rather than discover after the fact.

Something I haven't seen anyone mention: Section 4 contains two complete alternative wordings. One adds get_start_scheduler as a new query that defaults to get_scheduler. The other overloads the existing get_scheduler with the "started on" semantics.

The paper identifies a real dual-use problem - get_scheduler currently means both "which scheduler should I use for new work" and "which scheduler was I started on." Those aren't the same thing. But instead of picking a direction, it ships both options to LEWG.

I'd bet on get_start_scheduler getting consensus. The fallback-to-get_scheduler default means existing code keeps working, and the separation of concerns is cleaner. But LEWG is going to need to poll this explicitly, and I don't see it flagged as an open question in the change history.

I agree the two problems with change_coroutine_scheduler are real. Locals on the wrong scheduler is a correctness issue, and the invisible storage cost for all tasks is unfortunate. But look at the proposed alternative:

co_await ex::starts_on(s, [](parameters)->task<T, E> { logic }(arguments));

You're asking users to create a lambda, invoke it immediately, wrap it in starts_on, and co_await the result. That's four concepts chained together to do what co_await change_coroutine_scheduler(s) did in one line.

The paper calls this "a bit verbose." That's underselling it. The mental model goes from "I'm now on scheduler S" to "I'm spawning a nested coroutine that runs on scheduler S and I get the result back." Those are different programming models with different failure surfaces.

In Tokio you just spawn a task and the runtime handles affinity. Fifteen pages of wording changes to achieve what a runtime scheduler does by default.

Worth noting context: Kühl is a long-time P2300 contributor at Bloomberg and the author of P3552 (std::execution::task). This isn't a drive-by - he's fixing problems in his own design based on feedback from NB review.

That said, the paper's recommendation to require infallible schedulers for affine_on naturally favors the execution model where schedulers are lightweight and deterministic - which is the Bloomberg use case. LEWG might want to hear from implementers whose thread pool schedulers can't easily guarantee infallibility before treating the constraint as settled.

Putting the infallibility constraint in concrete terms. The paper is proposing a static check at connect time:

// The completion signatures of schedule(sch)
// with an unstoppable_token environment
// must be exactly:
//   completion_signatures<set_value_t()>
//
// If your scheduler can complete with
// set_error_t(E) or set_stopped_t(),
// affine_on(sndr) won't compile.

This is actually elegant. You find out at compile time, not when your server is handling 10k connections at 3 AM, that your scheduler can't guarantee affinity. The trade-off is that parallel_scheduler is locked out, but stdexec's static_thread_pool already meets this bar in practice - it just needs the signatures to declare it.