Implement p4223 attrs#2107
Closed
ispeters wants to merge 8 commits into
Closed
Conversation
ispeters
force-pushed
the
implement_p4223_attrs
branch
from
a89ff4f to
eb4ddb6
Compare
I realized that the completion domains reported by a `function` will be receiver environment-independant, so I deleted `__default_attrs`'s `_Queries` parameter, and I've updated the default to be a function of the given completion signatures using `completion_signatures<...>::__transform_reduce`.
It build and the existing tests pass, but I don't know if it works.
The tests confirm that we only report a completion domain on the channels we might complete on, and I had to fix some bugs in `function.hpp` to make the tests pass.
This diff just renames the bits and pieces that compute the completion domain of a `function`.
This is a partial implementation of constraining `function`'s constructor to accept only factories that produce senders that completion in the expected domain. It's partial because: - we're currently checking for a "matching" domain with `__same_as`, but we should be checking with some function of `common_domain`; and - there's no way to specify any expected domain other than `default_domain`. The current tests pass, which means we correctly allow factories that produce senders that completion in the default domain. We need tests that show we reject senders that *don't* complete in the default domain, and we need a way to use and validate the use of non-default domains.
The implementation is incomplete because we check for identical domains but should be checking for compatible domains with `common_domain`.
This diff modifies the `function` test that validates the domain-related constraints on `function`'s constructor. The old test required that `function` only erase senders with completion domains identitcal to those specified in the `function`'s type parameters; the intended design is that the erased sender's completion domains be _derived from_ the advertised domains. The new test requires the correct relationship, which forced a change in `function` to make the new test pass.
ispeters
force-pushed
the
implement_p4223_attrs
branch
from
eb4ddb6 to
0a52fdc
Compare
ispeters
commented
Jun 2, 2026
Comment on lines
+115
to
+121
| -> __join_env_t<__prop_t const &, env_of_t<_Receiver>> | ||
| { | ||
| return __env::__join(*__env_, STDEXEC::get_env(*static_cast<_Receiver const *>(this))); | ||
| } | ||
|
|
||
| private: | ||
| __prop_t *__env_; | ||
| __prop_t const *__env_; |
Contributor
Author
There was a problem hiding this comment.
@ericniebler, what do you think of this change? It resolves a compiler error where __join receives a __prop_t& but is expecting a __prop_t and can't find a conversion. The other thing that worked was to invoke __join like so:
return __env::__join(auto(*__env_), …);which seemed like a bunch of unnecessary copying.
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
1 participant
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.
P4223R0 calls for
functionto support a type parameter of the formattrs<…>that specifies the required attributes of the type-erased sender. This PR started out as an attempt to implement this missing feature inexec::function, but, along the way, I discovered that's not as trivial as I expected when I added the requirement to the paper. Unlikeexec::any_sender_of,functiondoesn't know the type of the sender it's erasing except in its constructor and, at that point, it knows only the type—it doesn't have the sender as a value untilconnectgets called—so we can't check that the erased sender's attributes meet the specified requirements.The simplest resolution to this conflict is obviously to just not support sender attributes in
functionbut, after consulting with @ericniebler on the subject, he pointed out thatget_completion_domainis a function of a sender's attributes, and it's a critical part of the algorithm customization logic. So, this PR is an implementation of the compromise: you can specify the required completion domains of the erased sender because we need only the sender's type to validate the constraint is met, and we can do that in thefunctionconstructor.New in this PR:
template <class...> exec::attrs, which is liketemplate <class...> exec::queriesbut for sender attribute queries instead of receiver environment queries;exec::__make_functionto support specifying the completion domain requirements of the erased sender;function's constructor to validate that the erased sender meets the aforementioned new domain requirements; andThe new requirement is that
__common_domain_t<ExpectedDomain, ActualDomain>is the same asExpectedDomain(i.e. the completion domain of the erased sender must be, or inherit from, the completion domain specified in thefunction's type).TODO:
__make_functionso you can specify required sender attributes without having to fully specify all of the type parametersget_completion_domain