brycelelbach / wg21_p2300_execution

`std::execution`, the proposed C++ framework for asynchronous and parallel programming.
Apache License 2.0
19 stars 6 forks source link

Regarding the mandate in `get_completion_signatures` #33

Open Chlorie opened 1 year ago

Chlorie commented 1 year ago

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 1 year ago

Pretty sure I agree with this, thanks.