[2026-03 LWG Motion 35] P3927R2 task_scheduler support for parallel bulk execution

[jensmaurer]

Fixes NB US 238-368 (C++26 CD).

Fixes #8869

Also fixes cplusplus/papers#2600
Also fixes cplusplus/papers#2503
Also fixes cplusplus/nbballot#943

[ericniebler]

looks good. thanks!

[jwakely]

There's a stray x in the pull request.

There are two places where the paper says that ts-domain::transform_sender is exposition-only, which are not in the pull request. But if it's exposition-only, why isn't it called transform-sender instead? If its name needs to be transform_sender then it's not exposition only, and the pull request is correct. I don't know.

[tkoeppe]

There are two places where the paper says that ts-domain::transform_sender is exposition-only, which are not in the pull request. But if it's exposition-only, why isn't it called transform-sender instead? If its name needs to be transform_sender then it's not exposition only, and the pull request is correct. I don't know.

Since ts-domain itself is an exposition-only class, I don't think it's observable whether its members are also exposition-only, and we don't need to also annotate members. E.g. the members of backend-for (added in the same paper) are also not annotated. I think that's fine, I don't see what else it could mean.

[jensmaurer]

Since ts-domain itself is an exposition-only class, I don't think it's observable whether its members are also exposition-only

I disagree here. get_completion_domain is specified to return ts-domain. Thus, even if this type doesn't have a known name, you can query for the presence of members using e.g. concepts or SFINAE. And you can trivially get a name for that type with using T = decltype(whatever);

[tkoeppe]

Hm, good point. We should look at the paper again, then, since indeed these members aren't marked up as expos-only, and in backend-for none of the members are marked expos-only. (Weirdly enough, the constructor of course needs to spell the declaration in expos-only italics, though it is (by your argument) not actually expos-only -- so the choice of font is in fact only an inadequate indicator in general.

[tkoeppe]

@ericniebler Could you please advice which parts of the paper are exposition-only?

[jwakely]

A transform_sender member function on a domain is used by std::execution::transform_sender if it exists, so its presence or absence has normative meaning. I don't think it should have been exposition only in the paper.

[jensmaurer]

I think omitting the "exposition-only" marking after "transform_sender" is good in the pull request, the paper is bad (in that regard), and life is overall splendid?

[ericniebler]

the user has no way of getting their hands on a backend-for object. that is why it is exposition only, and i was uncertain whether to annotate its members as such.

in the case of ts-domain, the type's name doesn't matter since users will not be uttering it. that is why it is exposition-only. but its transform_sender member is not marked exposition-only. it must be present. whoops, mea culpa

[jwakely]

but its transform_sender member is not marked exposition-only. it must be present.

It was marked expos-only in the paper, that's why we're asking.

[ericniebler]

It was marked expos-only in the paper, that's why we're asking.

right, i just noticed that. i agree that was an error.

[tkoeppe]

Thanks, @ericniebler!