Repository navigation
make starts_on work with sequence senders through __subscribe - #2451
Open
alwaysprince05 wants to merge 2 commits into
Open
alwaysprince05 wants to merge 2 commits into
alwaysprince05 wants to merge 2 commits into
Conversation
__seq::__sndr hooks STDEXEC::__subscribe when its last sender is a sequence sender: it runs the first sender, then subscribes the sequence. starts_on lowers to __sequence, so it now keeps the item types of a sequence child.
ericniebler
reviewed
Nov 12, 2026
| static constexpr auto __static_subscribe(_Self &&__self, _Receiver __rcvr) | ||
| noexcept(__nothrow_constructible_from<__subscribe_opstate_t<_Self, _Receiver>, | ||
| __copy_cvref_t<_Self, _Sender1>, | ||
| _Sender2, |
Collaborator
There was a problem hiding this comment.
should this be __copy_cvref_t<_Self, _Sender2>?
Contributor
Author
There was a problem hiding this comment.
Yes, thanks. __sndr2_ is forwarded as __copy_cvref_t<_Self, _Sender2> into a by-value parameter, so the check should use that type. Fixed in 0f59cca, in both __static_subscribe and connect (it had the same pattern).
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Step 2 from the plan in #2439, on top of #2443.
When the last sender of
__seq::__sndris a sequence sender, it now hooksSTDEXEC::__subscribe: it runs the first sender, then subscribes the sequence with a receiver that forwardsset_next.starts_onlowers to__sequence, sostarts_on(sch, seq)now keeps the item types ofseqand its items run onsch. Before this it was treated as a sequence of one item. Nothing instarts_onorsequence_senders.hppnames a specific algorithm.Two small things in exec were needed since stdexec can't see exec:
exec::sequence_sender_tagnow derives from a newSTDEXEC::__sequence_sender_tag, so__seq::__sndrcan tell its last sender is a sequence and use that tag itself.get_item_typesgets a generic hook: a sender can name__item_types_from_t<Self, Env...>as__mlist<Sender, SenderEnv...>, meaning its items are the items ofSenderinSenderEnv.__seq::__sndruses it for its last sender. Movingget_item_typesitself into stdexec would make this go away, but that pulls in most of the item types machinery, so I left it out. Happy to change it if you'd rather do it another way.Added tests in
test/exec/sequence/test_starts_on_sequence.cpp(item types, items run on the scheduler,starts_onoveriterate). test.exec and test.stdexec pass with Apple clang, gcc 14, and clang 16 + libc++; also checked g++-16 andSTDEXEC_ENABLE_EXTRA_TYPE_CHECKING. clang-format 21.1.8 clean.