Skip to content

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

@ericniebler

Description

@ericniebler
Collaborator

[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.

Activity

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[/+] on Dec 31, 2024
ericniebler

ericniebler commented on Jan 2, 2025

@ericniebler
CollaboratorAuthor

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.

added
needs-proposed-resolutionThis issue does not yet have a proposed resolution but needs one
and removed
needs-proposed-resolutionThis issue does not yet have a proposed resolution but needs one
on Jan 21, 2025
ericniebler

ericniebler commented on Feb 9, 2025

@ericniebler
CollaboratorAuthor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P0bugSomething isn't workingpending-wg21A paper or an LWG issue exits

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @ericniebler

        Issue actions

          specification of `completion-signatures-for` in [exec.snd.expos]/p39 is recursive · Issue #307 · cplusplus/sender-receiver