Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does basic-receiver need to constrain set_value/set_error/set_stopped on whether complete is invocable? #292

Open
lewissbaker opened this issue Oct 15, 2024 · 0 comments
Labels
discussion We need to talk about this; there's nothing actionable here yet wording

Comments

@lewissbaker
Copy link
Collaborator

The current specification for the exposition-only class basic-receiver defines its completion-functions to be constrained based on whether the impls-for<tag-t>::complete function is invocable.

For example:

  template<class Sndr, class Rcvr, class Index>
    requires valid-specialization<env-type, Index, Sndr, Rcvr>
  struct basic-receiver {                                       // exposition only
    using receiver_concept = receiver_t;

    using tag-t = tag_of_t<Sndr>;                               // exposition only
    using state-t = state-type<Sndr, Rcvr>;                     // exposition only
    static constexpr const auto& complete = impls-for<tag-t>::complete;   // exposition only

    template<class... Args>
      requires callable<decltype(complete), Index, state-t&, Rcvr&, set_value_t, Args...>
    void set_value(Args&&... args) && noexcept {
      complete(Index(), op->state, op->rcvr, set_value_t(), std::forward<Args>(args)...);
    }

    // ...

    basic-state<Sndr, Rcvr>* op;                           // exposition only
  };

Since a sender/operation is not allowed to form a call to set_value unless that completion-signature is listed in its set of completion-signatures, shouldn't we be using mandates instead of constraints here?

Is there any benefit to putting the constraints/requires-clause on the set_value/set_error/set_stopped functions?

@lewissbaker lewissbaker added discussion We need to talk about this; there's nothing actionable here yet wording labels Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion We need to talk about this; there's nothing actionable here yet wording
Projects
None yet
Development

No branches or pull requests

1 participant