`within` algorithm from P3955 by lucteo · Pull Request #288 · bemanproject/execution

lucteo · 2026-07-11T10:41:45Z

Also add additional concepts from the paper:

enter_scope_sender
enter_scope_sender_in
exit_scope_sender
exit_scope_sender_in
exit_scope_sender_of_t

Add utilities:

completion_storage -- allows storing the completions of an async operation to be used later.
elide -- helper to elide move ctor; useful for constructing operation states

Also add additional concepts from the paper: - `enter_scope_sender` - `enter_scope_sender_in` - `exit_scope_sender` - `exit_scope_sender_in` - `exit_scope_sender_of_t` Add utilities: - `completion_storage` -- allows storing the completions of an async operation to be used later. - `elide` -- helper to elide move ctor; useful for constructing operation states

- apply clang format - remove global qualification of class name - remove recursive include in `exit_scope_sender_in.hpp`

Fix issue when checking nothrow by connecting to the wrong receiver.

- Storing a cvref-removed receiver in `within` state object - Initialize the receiver before the operation state -- this caused UB - add appropriate headers in `exec-within.test.cpp` - remove unused variables from test

coveralls · 2026-07-13T18:57:06Z

coverage: 93.909% (+0.3%) from 93.571% — within-algo into main

dietmarkuehl

I'm not sure that I understand what within actually does (I should read the paper). There are a few comments which would be cool to address: in particular I think the single sender tools already exist and some of the other tools seem useful otherwise, too.

dietmarkuehl · 2026-07-13T21:11:04Z

+        if constexpr (std::is_nothrow_constructible_v<tuple_type, Tag, Args&&...>) {
+            storage.template emplace<tuple_type>(t, ::std::forward<Args>(args)...);
+        } else {
+            try {
+                storage.template emplace<tuple_type>(t, ::std::forward<Args>(args)...);
+            } catch (...) {
+                store_into_variant(storage, ::beman::execution::set_error_t{}, ::std::current_exception());
+            }


The "normal" pattern is to always use a try/catch block but execute the error work conditionally, thereby avoiding to duplicate the actual business logic (often the nothrow condition is stored into a constexpr variable):

try { storage.template emplace<tuple_type>(t, ::std::forward<Args>(args)...); } catch (...) { if constexpr (!std::is_nothrow_constructible_v<tuple_type, Tag, Args&&...>) { store_into_variant(storage, ::beman::execution::set_error_t{}, ::std::current_exception()); } }

dietmarkuehl · 2026-07-13T21:14:05Z

+                    ::beman::execution::detail::unreachable();
+                } else {
+                    ::std::apply(
+                        [&](const auto tag, auto&&... args) {


I guess this function wants to be noexcept as it just passes along references.

dietmarkuehl · 2026-07-13T21:15:37Z

+                            tag(::std::forward<Receiver>(receiver), ::std::forward<decltype(args)>(args)...);
+                        },
+                        // Make a copy, in case the tuple is destroyed by the completion call.
+                        tuple_type{::std::move(tuple_data)});


... and this move construction may possible throw in which case the exception should probably be caught and turned into a set_error(..., std::current_exception()) result.

dietmarkuehl · 2026-07-13T21:18:53Z

+    using result_t = std::invoke_result_t<F>;
+
+    /// Constructs the elision wrapper from callable `f`.
+    elide(F&& f) noexcept : f_(::std::forward<F>(f)) {}


Should the ctor be conditionally noexcept() based on the construction of f_ from F?

dietmarkuehl · 2026-07-13T21:23:37Z

+/// A receiver with environment `Env` that accepts every possible completion.
+template <typename Env = ::beman::execution::env<>>
+struct generic_receiver {
+    using receiver_concept = ::beman::execution::receiver_tag;
+
+    template <typename... T>
+    void set_value(T&&...) && noexcept {}
+    template <typename E>
+    void set_error(E&&) && noexcept {}
+    void set_stopped() && noexcept {}
+
+    auto get_env() const noexcept -> Env { ::beman::execution::detail::unreachable(); }
+};


Is this tool really specific to the exit_scope_sender_in or should it go into a separate header/component?

dietmarkuehl · 2026-07-13T21:25:26Z

+template <typename Sender, typename... Env>
+concept nothrow_connectable =
+    ::beman::execution::detail::nothrow_callable<::beman::execution::connect_t, Sender, generic_receiver<Env...>>;
+
+} // namespace beman::execution::detail


Likewise nothrow_connectable seems to be separately useful tool which should go into its own header/module.

dietmarkuehl · 2026-07-13T21:32:18Z

+template <typename Sig>
+inline constexpr bool is_value_completion_sig = false;
+template <typename... Args>
+inline constexpr bool is_value_completion_sig<::beman::execution::set_value_t(Args...)> = true;


There is something like that in include/beman/execution/detail/completion_signature.hpp: is_set_value. It isn't a bool variable template, though. The specialization is certainly needed just once and maybe its use should be unified.

dietmarkuehl · 2026-07-13T21:47:44Z

+template <typename... Sigs>
+struct single_value_sender;
+
+template <typename T, typename... Rest>
+    requires(!(::beman::execution::detail::is_value_completion_sig<Rest> || ...))
+struct single_value_sender<::beman::execution::set_value_t(T), Rest...> {
+    using type = T;
+};
+
+template <typename First, typename... Rest>
+    requires(!::beman::execution::detail::is_value_completion_sig<First>)
+struct single_value_sender<First, Rest...> : ::beman::execution::detail::single_value_sender<Rest...> {};
+


There is a concept single_sender which could probably do some of the work. It seems, single_value_sender also extracts the argument type, though.

single_sender is an exposition-only concept from the specification. It actually uses single_sender_value_type which is an exposition-only type alias also from the specification. I'd think these can be used directly.

dietmarkuehl · 2026-07-13T21:50:28Z

+    }
+
+  private:
+    /// Helper that yield the signatures of the `within` sender `Sender` when used with the environment `Env`.


Suggested change

/// Helper that yield the signatures of the `within` sender `Sender` when used with the environment `Env`.

/// Helper that yields the signatures of the `within` sender `Sender` when used with the environment `Env`.

lucteo requested review from camio and dietmarkuehl as code owners July 11, 2026 10:41

lucteo added 8 commits July 12, 2026 11:42

CI fixes

255cea4

- apply clang format - remove global qualification of class name - remove recursive include in `exit_scope_sender_in.hpp`

Update modules

6ad4a34

Fix issue when checking nothrow by connecting to the wrong receiver.

Fix missing include to env

4125dba

Add missing sender_in include

6d30be6

Fix missing includes

297c5af

Fix assert usage in within

20ad718

Include <cassert> before import std

c2ff435

Receiver and test fixes

ff3b5fc

- Storing a cvref-removed receiver in `within` state object - Initialize the receiver before the operation state -- this caused UB - add appropriate headers in `exec-within.test.cpp` - remove unused variables from test

lucteo added 3 commits July 13, 2026 23:30

Add tests for completion_storage

ea6c641

Merge remote-tracking branch 'origin/main' into within-algo

55a2484

Fix missing import in new test.

24bc7c3

dietmarkuehl reviewed Jul 13, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

`within` algorithm from P3955#288

`within` algorithm from P3955#288
lucteo wants to merge 12 commits into
mainfrom
within-algo

lucteo commented Jul 11, 2026

Uh oh!

coveralls commented Jul 13, 2026 •

edited

Loading

Uh oh!

dietmarkuehl left a comment

Uh oh!

dietmarkuehl Jul 13, 2026

Uh oh!

dietmarkuehl Jul 13, 2026

Uh oh!

dietmarkuehl Jul 13, 2026

Uh oh!

dietmarkuehl Jul 13, 2026

Uh oh!

dietmarkuehl Jul 13, 2026

Uh oh!

dietmarkuehl Jul 13, 2026

Uh oh!

dietmarkuehl Jul 13, 2026

Uh oh!

dietmarkuehl Jul 13, 2026

Uh oh!

dietmarkuehl Jul 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	/// Helper that yield the signatures of the `within` sender `Sender` when used with the environment `Env`.
	/// Helper that yields the signatures of the `within` sender `Sender` when used with the environment `Env`.

Uh oh!

Conversation

lucteo commented Jul 11, 2026

Uh oh!

coveralls commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dietmarkuehl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

coveralls commented Jul 13, 2026 •

edited

Loading