let_value does not propagate nothrow-connect-ness
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- backend-api-design
Research direction
Reproduce the Godbolt example and inspect stdexec/execution.hpp around let_value, __connectable, and __nothrow_connectable. Trace why the shown noexcept lambda and just() sender do not satisfy the nothrow assertion, then determine whether the behavior is intended and add or update regression coverage if a change is required.
Written by the indexing model from the issue text.
Description
Consider this code:
#include <stdexec/execution.hpp>
void test() {
auto s1 = stdexec::let_value(
stdexec::just(),
[]() noexcept {
return stdexec::just();
}
);
static_assert(stdexec::__detail::__connectable<decltype(s1), stdexec::__sync_wait::__receiver_t<decltype(s1)>>);
static_assert(stdexec::__nothrow_connectable<decltype(s1), stdexec::__sync_wait::__receiver_t<decltype(s1)>>); // <
}
(Godbolt link: https://godbolt.org/z/hn5MG7dqe)
Compilation fails on the line marked with <, which suggests than s1 is a valid sender, but its connect CPO is declared as throwing.
This is surprising: as fas as I can see, there is no room for an exception in this code, since just() returns nothrow-connectable sender, and lambda itself is declared as non-throwing. let_value internal implementation is hard to follow (in particular, while reading [exec] I wasn't able to find what domain really is), so I can't pinpoint source of confusion any further.
Is this behavior intended?
- Dominant language
- C++
- Stars
- 2.4k
- Forks
- 270
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 43
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from NVIDIA/stdexec
-
inline_scheduler's namespace-scope static_assert fails under nvcc (private nested __sender access) Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
-
Difficulty 4/5 3-5 days Newbie friendliness 65/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
duckdb/duckdb-wasm#2258 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
objectionary/eo-graphs#75 ·
-
Coarray integration tests carry no LABELS, so run_tests.py silently skips them under every backend Opencoarray
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
FISCO-BCOS/FISCO-BCOS#5642 ·