Issues

can a sender's `connect` member fn be private if it befriends `execution::connect_t`?

cplusplus/sender-receiver#342 · opened

on Jul 3, 2025

4

should we permit `get_completion_signatures<Sndr,Env>()` to return a subset of `get_completion_signatures<Sndr>()`

cplusplus/sender-receiver#339 · opened

on Jun 18, 2025

Figure out how/whether we should use P2830 "Standardized Constexpr Type Ordering" in sender/receiver

cplusplus/sender-receiver#330 · opened

on Feb 15, 2025

3

[exec.snd.concepts] `sender_to` concept should avoid checking that the receiver's completion-methods are present

cplusplus/sender-receiver#327 · opened

on Feb 8, 2025

Should `set_value/error/stopped` CPOs require that member-functions return `void`?

cplusplus/sender-receiver#323 · opened

on Feb 4, 2025

2

`when_all(just())` shouldn’t have a `set_stopped_t()` completion signature

cplusplus/sender-receiver#297 · opened

on Oct 22, 2024

`run_loop::schedule()` should not have `set_stopped_t()` in its completion signatures if passed an env with an `unstoppable_token`

cplusplus/sender-receiver#294 · opened

on Oct 16, 2024

run_loop::run-loop-sender should remove the item from the list when a stop-request is sent

cplusplus/sender-receiver#293 · opened

on Oct 15, 2024

7

should queries be required to have a UUID so that there is a global canonical ordering?

cplusplus/sender-receiver#289 · opened

on Aug 28, 2024

2

Should let_value destroy its predecessor operation-state eagerly to allow storage reuse?

cplusplus/sender-receiver#287 · opened

on Aug 14, 2024

2

Why do we allow directly querying schedulers, but require receivers to return a separate environment object?

cplusplus/sender-receiver#286 · opened

on Aug 13, 2024

Add support for strand-schedulers

cplusplus/sender-receiver#285 · opened

on Aug 12, 2024

Clarify the semantics/requirements of the get_scheduler query

cplusplus/sender-receiver#284 · opened

on Aug 3, 2024

1

Definition of `SCHED-ATTRS` incorrectly assumes that schedule operations that complete with set_stopped will complete on that scheduler

cplusplus/sender-receiver#283 · opened

on Aug 1, 2024

5

grant `connect` permission to return a type other than `decltype(sndr.connect(rcvr))`

cplusplus/sender-receiver#281 · opened

on Jul 19, 2024

1

Should the default implementation of `bulk` support cancellation?

cplusplus/sender-receiver#278 · opened

on Jul 12, 2024

5

`bulk` doesn't explicitly grant permissions for customisations to execute `f` concurrently

cplusplus/sender-receiver#277 · opened

on Jul 12, 2024

1

`bulk` does not specify what customizations need to do with exceptions thrown from invocations of `f`

cplusplus/sender-receiver#276 · opened

on Jul 12, 2024

4

bulk doesn't give the caller a way to constrain how function can be executed

cplusplus/sender-receiver#275 · opened

on Jul 12, 2024

4

Define a policy for resuming leaf operations that avoids running continuations inline on context that triggered completion

cplusplus/sender-receiver#269 · opened

on Jul 4, 2024

5

Update `connect-awaitable` specification to use the receiver's allocator to allocate the coroutine-frame

cplusplus/sender-receiver#268 · opened

on Jul 4, 2024

1

Improvements to receiver interface (explicit datum types, generic set_result)

cplusplus/sender-receiver#264 · opened

on Jul 4, 2024

1

Change `split` algorithm to be an algorithm over an async-scope

cplusplus/sender-receiver#263 · opened

on Jul 3, 2024

1

Add ability to know when computing completion-signatures whether the call to connect() will throw

cplusplus/sender-receiver#247 · opened

on Jun 14, 2024

3

remove `get_completion_signatures`

cplusplus/sender-receiver#246 · opened

on Jun 14, 2024

5

Navigation Menu

Repository navigation

Issues

can a sender's `connect` member fn be private if it befriends `execution::connect_t`?

should we permit `get_completion_signatures<Sndr,Env>()` to return a subset of `get_completion_signatures<Sndr>()`

Figure out how/whether we should use P2830 "Standardized Constexpr Type Ordering" in sender/receiver

[exec.snd.concepts] `sender_to` concept should avoid checking that the receiver's completion-methods are present

Should `set_value/error/stopped` CPOs require that member-functions return `void`?

`when_all(just())` shouldn’t have a `set_stopped_t()` completion signature

`run_loop::schedule()` should not have `set_stopped_t()` in its completion signatures if passed an env with an `unstoppable_token`

run_loop::run-loop-sender should remove the item from the list when a stop-request is sent

should queries be required to have a UUID so that there is a global canonical ordering?

Should let_value destroy its predecessor operation-state eagerly to allow storage reuse?

Why do we allow directly querying schedulers, but require receivers to return a separate environment object?

Add support for strand-schedulers

Clarify the semantics/requirements of the get_scheduler query

Definition of `SCHED-ATTRS` incorrectly assumes that schedule operations that complete with set_stopped will complete on that scheduler

grant `connect` permission to return a type other than `decltype(sndr.connect(rcvr))`

Should the default implementation of `bulk` support cancellation?

`bulk` doesn't explicitly grant permissions for customisations to execute `f` concurrently

`bulk` does not specify what customizations need to do with exceptions thrown from invocations of `f`

bulk doesn't give the caller a way to constrain how function can be executed

Define a policy for resuming leaf operations that avoids running continuations inline on context that triggered completion

Update `connect-awaitable` specification to use the receiver's allocator to allocate the coroutine-frame

Improvements to receiver interface (explicit datum types, generic set_result)

Change `split` algorithm to be an algorithm over an async-scope

Add ability to know when computing completion-signatures whether the call to connect() will throw

remove `get_completion_signatures`