Created on 2025-11-05.00:00:00 last changed 6 days ago
Proposed resolution:
This wording is relative to N5032.
Modify [exec.inline.scheduler] as indicated:
-3- Let `sndr` be an expression of type inline-sender, let `rcvr` be an expression such that receiver_of<decltype((rcvr)), CS> is `true` where `CS` is completion_signatures<set_value_t()>, then:
- (3.1) — the expression `connect(sndr, rcvr)` has type inline-state<remove_cvref_t<decltype((rcvr))>> and is potentially-throwing if and only if `((void)sndr, auto(rcvr))` is potentially-throwing, and
- (3.2) — the expression get_completion_scheduler<set_value_t>(get_env(sndr)) has type `inline_scheduler`
and is potentially-throwing if and only if `get_env(sndr)` is potentially-throwing.
Modify [exec.run.loop.types] as indicated:
-7- Let `sndr` be an expression of type `run-loop-sender`, let `rcvr` be an expression such that
receiver_of<decltype((rcvr)), CS>is `true` where `CS` is the `completion_signatures` specialization above. Let `C` be either `set_value_t` or `set_stopped_t`. Then:
- (7.1) — The expression
connect(sndr, rcvr)has typerun-loop-opstate<decay_t<decltype((rcvr))>>and is potentially-throwing if and only if(void(sndr), auto(rcvr))is potentially-throwing.- (7.2) — The expression
get_completion_scheduler<C>(get_env(sndr))is potentially-throwing if and only if `sndr` is potentially-throwing,has type `run-loop-scheduler`,and compares equal to the `run-loop-scheduler` instance from which `sndr` was obtained.
[ 2026-01-16; Jonathan provides updated wording ]
LWG believes the original issue discussion is wrong to say that `get_env(sndr)` can never throw, because the expression `sndr` itself could throw. However, we already state that `get_env` and `get_completion_scheduler` do not throw, so it's redundant to say that `get_completion_scheduler(get_env(sndr))` only throws if `sndr` throws. If nothing except `sndr` in that expression is allowed to throw, then it's just stating the obvious.
[ 2026-01-16; Reflector poll. ]
Set priority to 4 after reflector poll.
"[exec.run.loop.types] (7.2) has the same redundancy."
This wording is relative to N5014.
Modify [exec.inline.scheduler] as indicated:
-3- Let `sndr` be an expression of type inline-sender, let `rcvr` be an expression such that receiver_of<decltype((rcvr)), CS> is `true` where `CS` is completion_signatures<set_value_t()>, then:
- (3.1) — the expression `connect(sndr, rcvr)` has type inline-state<remove_cvref_t<decltype((rcvr))>> and is potentially-throwing if and only if `((void)sndr, auto(rcvr))` is potentially-throwing, and
- (3.2) — the expression get_completion_scheduler<set_value_t>(get_env(sndr)) has type `inline_scheduler`
and is potentially-throwing if and only if `get_env(sndr)` is potentially-throwing.
[exec.inline.scheduler] bullet (3.2) reads:
- (3.2) — the expression get_completion_scheduler<set_value_t>(get_env(sndr)) has type `inline_scheduler` and is potentially-throwing if and only if `get_env(sndr)` is potentially-throwing.
`get_env(sndr)` is never potentially-throwing because it mandates that `sndr.get_env()` cannot throw, see [exec.get.env].
also, get_completion_scheduler<set_*_t>(attrs) mandates that attrs.query(get_completion_scheduler<set_*_t>) cannot throw.| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2026-01-16 18:38:44 | admin | set | messages: + msg15869 |
| 2026-01-16 15:56:07 | admin | set | messages: + msg15864 |
| 2025-11-15 07:17:38 | admin | set | messages: + msg15740 |
| 2025-11-05 00:00:00 | admin | create | |