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

Regarding the mandate in get_completion_signatures #27

Closed
ericniebler opened this issue Dec 7, 2023 · 1 comment · Fixed by #155
Closed

Regarding the mandate in get_completion_signatures #27

ericniebler opened this issue Dec 7, 2023 · 1 comment · Fixed by #155
Labels
bug Something isn't working

Comments

@ericniebler
Copy link
Collaborator

Issue by Chlorie
Thursday Feb 16, 2023 at 14:24 GMT
Originally opened as brycelelbach/wg21_p2300_execution#33


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 ericniebler added the bug Something isn't working label Dec 7, 2023
@ericniebler
Copy link
Collaborator Author

Comment by ericniebler
Thursday Feb 16, 2023 at 15:28 GMT


Pretty sure I agree with this, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant