Currently in 11.7.2.1. [exec.complsigs], a mandate is placed on customizations of get_completion_signatures:
Mandates: valid-completion-signatures<Sigs>, where Sigs names the type tag_invoke_result_t<get_completion_signatures_t, S, E>.
This might complicate implementations of senders that are more template-involved in the computation of completion signatures. For example, one could implement a complex logic of completion signatures with if constexprs in the customization function like this, back when dependent_completion_signatures was still a thing:
template <typename Env>
constexpr friend auto tag_invoke(get_completion_signatures_t, Sender&& s, Env&&) noexcept
{
if constexpr (something)
return some_comp_sigs{};
else if constexpr (something else)
return some_other_comp_sigs{};
else // This environment type isn't supported by this sender
return dependent_completion_signatures{};
}
But after the removal of dependent_completion_signatures, some constraint (which might be arbitrarily complex depending on the number of branches in the logic) must be put onto the customization, since if we just return some random types in the unsupported case, the failed mandate would cause a hard error (static_assert failure) instead of just being ill-formed and being just a substitution error.
In conclusion, it might be more beneficial for sender implementers to make get_completion_signatures(sender, env) ill-formed if it doesn't return valid-completion-signatures, rather than to hard error with mandates; or we can re-introduce dependent_completion_signatures to support this case, although the name might not be appropriate for this use case.
ericniebler
commented
10 months ago
Currently in 11.7.2.1. [exec.complsigs], a mandate is placed on customizations of
get_completion_signatures:This might complicate implementations of senders that are more template-involved in the computation of completion signatures. For example, one could implement a complex logic of completion signatures with
if constexprs in the customization function like this, back whendependent_completion_signatureswas still a thing:But after the removal of
dependent_completion_signatures, some constraint (which might be arbitrarily complex depending on the number of branches in the logic) must be put onto the customization, since if we just return some random types in the unsupported case, the failed mandate would cause a hard error (static_assertfailure) instead of just being ill-formed and being just a substitution error.In conclusion, it might be more beneficial for sender implementers to make
get_completion_signatures(sender, env)ill-formed if it doesn't returnvalid-completion-signatures, rather than to hard error with mandates; or we can re-introducedependent_completion_signaturesto support this case, although the name might not be appropriate for this use case.