The lack of goal makes it hard to review in the context of WG21. I keep thinking that a series of blog post would collect more readership. I.E, because it proposes nothing, and aim not at being presented, there is no point in trying to make it easier to present. I will note that the title implies some sort of proposed change, which will confuse people in WG21. There is some fluff here, that does not help neither the reader nor the paper, namely the disclosure section. just replace that by "This is an informational paper which does not propose any change to the standard". On to the thesis, with the caveat I'm not a library expert these days, let alone a executor or networking ts. I'm not the right person to review this but I tried! I felt it was a bit a bit one sided, the conclusion of P3941 is
In general *it seems unlikely that all schedulers can be constrained to be infallible*. As a result affine_on and, by extension, task won’t be usable with all schedulers if affine_on insists on using only infallible schedulers. If there are fallible schedulers, there aren’t any good options for using them with a task. Note that affine_on can fail and get cancelled (due to the main work failing or getting cancelled) but `affine_on can still guarantee that execution resumes on the expect execution agent when it uses an infallible scheduler.
I.E it's not saying that scheduling is infallible, rather than there is a mismatch between on one side scheduling can fail, and on the other, we have no clue what to do when scheduling fails (ie we don;t know where to get back to). In fact, my main question here is, LEWG decided in the context of P3941 to have `affine` require an infallible scheduler, which in effect seems to imply a task cannot be executed on a parallel scheduler. Am I correct? And if so, isn't that... limitating? Can that be improved? There was a different suggestion here, that is not mentioned or pondered. Maybe doing so would be informative. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3941r4.html#allow-... Nits: `affine_on` -> `affine` (it was renamed at some point)