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

specification of completion-signatures-for in [exec.snd.expos]/p39 is recursive #307

Open
ericniebler opened this issue Dec 31, 2024 · 1 comment
Labels
bug Something isn't working P0

Comments

@ericniebler
Copy link
Collaborator

ericniebler commented Dec 31, 2024

[exec.snd.expos]/p24 reads:

For a subexpression sndr let Sndr be decltype((sndr)). Let rcvr be a
receiver with an associated environment of type Env such that
sender_in<Sndr, Env> is true. completion-signatures-for<Sndr, Env>
denotes a specialization of completion_signatures, the set of whose template
arguments correspond to the set of completion operations that are potentially
evaluated as a result of starting ([exec.async.ops]) the operation state that
results from connecting sndr and rcvr. When sender_in<Sndr, Env> is
false, the type denoted by completion-signatures-for<Sndr,
Env>
, if any, is not a specialization of completion_signatures.

This para is trying to specify the return type of basic-sender::get_completion_signatures, but it immediately goes off the rails when it tests for the satisfaction of sender_in<Sndr, Env>. The sender_in<Sndr, Env> concept requires that get_completion_signatures(sndr, env) is well-formed and that its type is a specialization of completion_signatures. But the return type of get_completion_signatures(sndr, env) is exactly the thing this para is trying to define!

I think that we need to add a impls-for<Tag>::get-completion-signatures hook and define it for all the algorithms. which would be a large change. i'm not sure if there is an easier way.

@ericniebler ericniebler added bug Something isn't working P0 labels Dec 31, 2024
@ericniebler ericniebler changed the title specification of _completion-signatures-for_ in [exec.snd.expos]/p39 is recursive specification of completion-signatures-for in [exec.snd.expos]/p39 is recursive Dec 31, 2024
@ericniebler
Copy link
Collaborator Author

ericniebler commented Jan 2, 2025

Proposed resolution:

replace [exec.snd.expos]/p24 with:

Let type Sndr be a (possibly const-qualified) specialization of basic-sender or an lvalue reference of such, and let Rcvr be the type of a receiver with an associated environment of type Env. If the type basic-operation<Sndr, Rcvr> is well-formed, let op be an lvalue subexpression of that type. completion-signatures-for<Sndr, Env> denotes a specialization of completion_signatures, the set of whose template arguments corresponds to the set of completion operations that are potentially evaluated ([basic.def.odr]) as a result of evaluating op.start(). Otherwise, the type denoted by completion-signatures-for<Sndr, Env>, if any, is not a specialization of completion_signatures.

Recommended practice: When the type basic-operation<Sndr, Rcvr> is ill-formed, implementations are encouraged to use the type denoted by completion-signatures-for<Sndr, Env> to communicate to users why.

@ericniebler ericniebler added needs-proposed-resolution This issue does not yet have a proposed resolution but needs one and removed needs-proposed-resolution This issue does not yet have a proposed resolution but needs one labels Jan 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working P0
Projects
None yet
Development

No branches or pull requests

1 participant