Introduce exec::function<...>

[ispeters]

This PR proposes a new type-erased sender named exec::function. There's an in-code comment giving a bunch of examples, but a simple example is:

exec::function<int(int)> fn(42, [](int i) { return ex::just(i); });

auto [result] = ex::sync_wait(std::move(fn)).value();

assert(result == 42);

There are a bunch of TODOs left, including lots of tests that are missing, but the API is ready to collect early feedback. If this looks like a promising direction, I intend to write a paper for Brno proposing this type for inclusion in C++29.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[ericniebler]

why capture a function and arguments instead of just a sender that aggregates the arguments? what does lazy construction of the sender offer here?

could this be implemented in terms of:

template <class Result,
          class ReceiverQueries = queries<>,
          class Completions = completion_signatures<set_error_t(exception_ptr),
                                                    set_stopped_t()>,
          class SenderQueries = queries<>>
auto function(auto sndr) 
{
  using _completions_t =
    __minvoke<__mpush_back<__q<completion_signatures>>, Completions, set_value_t(Result)>;

  using _sender_t =
    any_sender<any_receiver<_completions_t, ReceiverQueries>, SenderQueries>;

   return _sender_t(let_value(read_env(get_frame_allocator),
                              [=](auto const& alloc)
                              {
                                return __uses_frame_allocator(sndr, alloc);
                              }));
}

EDIT: also, the exec::function interface suggests to me that it would be used like:

exec::function<int(int)> fn([](int i) { return ex::just(i); });

auto [result] = ex::sync_wait(fn(42)).value();

the lazy construction of the sender would then makes sense.

[ericniebler]

i still don't understand why this utility captures args and a function that returns a sender instead of just capturing the resulting sender. what benefit do we gain from lazily constructing the sender at connect time?

[ericniebler]

/ok to test bcdaae2

[ispeters]

i still don't understand why this utility captures args and a function that returns a sender instead of just capturing the resulting sender. what benefit do we gain from lazily constructing the sender at connect time?

Yeah, sorry, I was responding to the easier feedback before getting to this philosophical question and it's not surprising you have this question—somewhere between having the idea for this PR and actually publishing it, I got distracted by the details and didn't include a very good motivation. Let me try to fix that.

The back story is that I'm looking into the benchmark that Vinnie and Steve have published here. I'm still working on developing a deep enough understanding of the benchmark to have intelligent opinions about it but my initial impression is that the coroutine code is very well written (unsurprising given the author's expertise), but the sender code is unidiomatic, suggesting to me that the author is less experienced with senders than with coroutines. I'd like to improve the sender code to make the comparison between approaches as fair as possible.

One of the apparent weaknesses of senders that is exposed in the benchmark is that it's more difficult to optimize the allocation patterns of an any_sender_of than that of a coroutine task type (capy::task in the benchmark, but I think it generalizes). There are probably several ways to tackle this problem, but capturing arguments plus a sender factory is an idea I had while ruminating on the issue that I think could prove very useful.

The idea behind this exec::function is that it's sort of a "better coroutine". By capturing an arg tuple + sender factory, the initial sender never has to allocate, although, because we're still doing type erasure, we obviously have to support allocating the operation state modulo any small buffer optimization. Ensuring the opstate allocation happens through the newly-introduced "frame allocator", lets this type benefit from the same allocation optimizations that Vinnie and co. have made in Capy. If the frame allocator is what Vinnie calls a "recycling allocator" then the stack-like nature of nested operations can be reflected in a stack-like allocation pattern that leads to amortized zero allocations per operation.

The usage I expect would look like this:

struct interface {
  virtual exec::function<int(interface*) noexcept> get_int() noexcept = 0;
};

struct impl : interface {
  exec::function<int(interface*) noexcept> get_int() noexcept override {
    return exec::function<int(interface*) noexcept>(this, [](interface* base) noexcept {
      auto* self = static_cast<impl*>(base);
      // presumably some more interesting composition of senders in practice
      return ex::just(self->i_);
    });
  }

 private:
  int i_;
};

Letting myself think grandiose thoughts, I could imagine extending this with a language feature that lets you use coroutine syntax to let the compiler write the actual sender for you, like this:

exec::function<std::string(int)> async_to_string(int i) {
  co_return std::format("{}", i);
}

For cases where async_to_string is declared in a header and defined in a .cpp file, the type erasure, with the concomitant allocation, can't really be avoided, but for cases where the compiler can see the body of async_to_string at the call site, I could imagine the compiler generating a parent operation that has space in its opstate for the child opstate, eliding any allocations. Imagining even further, it'd be nice to have an "auto"-like syntax for inline async functions where the compiler not only generates the sender implementation, but also computes the full set of completion signatures to make the declaration more terse. Maybe something like

exec::function<ex::sender_tag> async_to_string(int i) {
  // compiler computes set_value_t(std::string) and set_error_t(std::exception_ptr)
  // but not set_stopped_t() because this coroutine doesn't complete with stopped
  co_return std::format("{}", i);
}

[ericniebler]

By capturing an arg tuple + sender factory, the initial sender never has to allocate

so the allocation this saves is the one that can potentially happen when type-erasing a sender? could you achieve the same thing with a (non-type-erasing) sender adaptor that returns a type-erased opstate from connect?

[ericniebler]

/ok to test ede4ba2

[ispeters]

By capturing an arg tuple + sender factory, the initial sender never has to allocate

so the allocation this saves is the one that can potentially happen when type-erasing a sender?

Yes.

could you achieve the same thing with a (non-type-erasing) sender adaptor that returns a type-erased opstate from connect?

I don't think so, but maybe you can see a way? Suppose we had sender auto exec::type_erase(sender auto&&); I think you can't get around the fact that the input sender is of arbitrary size so either the return type has to fully specify the type of the input plus whatever wrapping it does, or you have to type-erase the input and risk an eager allocation.

Also, fwiw, I'm open to feedback on the name of this type. If you look at the commit history, you can see I originally named this thing capy_sender because the immediate application is the Capy-sourced benchmark. Then, I thought io_sender would be a better name since that's what Vinnie claims this approach is best for. I finally landed on function because:

• Robert's description of how senders work describes how you first curry your arguments into a sender, then you allocate a frame in the form of an operation state, and then you actually execute the async function by invoking start so this type implements a kind of platonic sender—curry, allocate, execute—which suggests that it's a type-erased async function; and
• Robert has also said that he believes everything in the std::execution namespace is presumptively async so std::execution::async_function<void()> is redundant—we can just have std::execution::function<void()>.

That said, the confusion you expressed earlier about the interface suggests to me that the name might be a problem. Perhaps something like curried<void()>, sender_factory<void()>.

[ericniebler]

Suppose we had sender auto exec::type_erase(sender auto&&); I think you can't get around the fact that the input sender is of arbitrary size so either the return type has to fully specify the type of the input plus whatever wrapping it does

yes, that is what i was asking about. what is the problem with doing an ordinary sender adaptor?

[ericniebler]

/ok to test fa12a41

[ispeters]

Suppose we had sender auto exec::type_erase(sender auto&&); I think you can't get around the fact that the input sender is of arbitrary size so either the return type has to fully specify the type of the input plus whatever wrapping it does

yes, that is what i was asking about. what is the problem with doing an ordinary sender adaptor?

I'm not certain whether you're asking, "why is function a type instead of an algorithm?", or "why does this thing—whether type or algorithm—have to type-erase a factory instead of adapting a concrete sender?"

Regarding "why a type?", I'm not really fussed either way, except that the motivating use case requires that users be able to spell a type so they can return it from functions declared-but-not-defined in headers. So if you're looking for an algorithm to be the "constructor" instead of using a regular type with a constructor, that's fine by me, but I think there needs to be a type regardless.

Regarding "why does this type-erase the factory?", I can't see another way to achieve my goal, but I'm open to counterexamples. I want to be able to write this sort of thing:

// iface.hpp
#include <memory>

struct iface {
  virtual ~iface() = default;

  virtual $type$ async_virtual(int idx) = 0;
};

std::unique_ptr<iface> make_iface();

// impl.hpp
#include "iface.hpp"

struct impl : iface {
  $type$ async_virtual(int idx) override;

  $type$ async_member();
};

// impl.cpp
#include "impl.hpp"

#include <execution>

sender auto some_sender(int idx) {
  // some arbitrary composition of senders
}

sender auto other_sender() {
  // some other arbitrary composition of senders
}

$type$ impl::async_virtual(int idx) {
  // return some function of some_sender(idx);
}

$type$ impl::async_member() {
  // return some function of other_sender();
}

std::unique_ptr<iface> make_iface() {
  return std::unique_ptr<impl>();
}

// main.cpp
#include "impl.hpp":

int main() {
  auto p = make_iface();

  sync_wait(p->async_virtual(42));

  auto* q = static_cast<impl*>(p.get());

  // async_member's declaration is visible, but not its definition
  sync_wait(q->async_member());
}

If we imagine we have sender auto type_erase(sender auto&&) and use it in impl.cpp, I think you have this:

$type$ impl::async_virtual(int idx) {
  return type_erase(some_sender(idx));
}

$type$ impl::async_member() {
  return type_erase(other_sender());
}

Given the declaration of some_sender and other_sender are not visible outside impl.cpp, main.cpp doesn't know how big the concrete sender returned from type_erase is, so I think you inevitably have to do the standard small buffer-optimized type-erasure dance and risk an allocation. The only alternative I can see is for the specific types of the composed senders to leak out of the interface through something equivalent to using $type$ = decltype(type_erase(...));, which I think makes it inappropriate for use as the return type of virtual member functions, or separately-compiled functions of any kind.

If $type$ is an instantiation of the proposed function, then impl.cpp looks like this (assuming the senders returned from some_sender and other_sender complete with set_value_t() for simplicity):

exec::function<void(int)> impl::async_virtual(int idx) {
  return exec::function<void(int)>(
      std::move(idx), // it bugs me that this move is required in the current code…
      [](int idx) { return some_sender(idx); });
}

exec::function<void()> impl::async_member() {
  return exec::function<void()>([] { return other_sender(); });
}

The type-erased sender factory is of constant size (because I restrict the factory to be trivially-copyable types no bigger than two pointers to accommodate regular function pointers and member function pointers), and the storage for the factory's arguments is knowable and a function of the class template parameters because they're expressed in the function type.

Does that answer your question? Do you see another way to accomplish the goal? A function<int(???)> is like a task<int> but with better-timed allocation because it erases less.

[ericniebler]

thanks, i understand now what problem you're solving. it's very interesting. 🤔

[ericniebler]

/ok to test 025628b

[ericniebler]

/ok to test 67066b8

[ispeters]

The test failure on GCC 14 Debug with ASAN enabled is going to be tricky; GCC doesn't support ASAN on Apple silicon, which is my only dev environment.

[ispeters]

Unfortunately for me, the (gcc 14, Debug, ASAN) failure doesn't repro with Homebrew Clang 22.1.4, Debug, ASAN.

The failures are in test_function.cpp here:

stdexec/test/exec/test_function.cpp

Lines 374 to 375 in 67066b8

	func2_t f4(45, ex::just);
	func3_t f5(45, ex::just);

stdexec/test/exec/test_function.cpp

Line 391 in 67066b8

REQUIRE(f4 == f5);

and here:

stdexec/test/exec/test_function.cpp

Lines 465 to 466 in 67066b8

	func1_t f3(45, ex::just);
	func2_t f4(45, ex::just);

stdexec/test/exec/test_function.cpp

Line 478 in 67066b8

REQUIRE(f3 == f4);

I'm wondering if GCC's ASAN implementation is mucking with this operator== implementation in some way, like initializing the std::byte make_sender_[sizeof(void *) * 2] member with garbage, or something:

stdexec/include/exec/function.hpp

Lines 199 to 205 in 67066b8

	friend constexpr bool operator==(_func_impl const &lhs, _func_impl const &rhs)
	noexcept(noexcept(_equal(lhs.args_, rhs.args_)))
	{
	return lhs.make_op_ == rhs.make_op_
	&& std::ranges::equal(lhs.make_sender_, rhs.make_sender_)
	&& _equal(lhs.args_, rhs.args_);
	}

[ericniebler]

comments inline..

[ericniebler]

i would expect the factory to be the first parameter, followed by the arguments.

[ispeters]

So, I'm open to that, but my reason for the current order is that it puts the arguments closer to the argument list of a lambda than the other order and, since Args... is deduced for the class rather than the constructor, there's no parsing ambiguity by doing it in this order.

Regarding "putting the arguments closer", I mean this:

function<int(foo, bar, baz, quux)> async(foo f, bar b1, baz b2, quux q) {
  return function<int(foo, bar, baz, quux)>(
    std::move(f), std::move(b1), std::move(b2), std::move(q),
    [](auto f, auto b1, auto b2, auto q) {
      // the function ctor arguments line up more nicely with this
      // lambda's arguments in this order, rather than having the
      // ctor arguments after the closing brace, far away from the
      // lambda's arguments
      return sender_algo(std::move(f), std::move(b1), std::move(b2), std::move(q));
    });
}

[ericniebler]

have you considered an interface like:

function<int(foo, bar, baz, quux)> async(foo f, bar b1, baz b2, quux q) {
  return make_function(
    sender_algo, std::move(f), std::move(b1), std::move(b2), std::move(q));
}

it would be defined something like:

template <class Queries, class SenderFactory, class... Args>
using __result_t =
  value_types_of_t<__invoke_result_t<SenderFactory, Args...>,
                   __env_for_queries<Queries>,
                   type_identity,
                   type_identity>;

template <class Queries = queries<>, class SenderFactory, class... Args>
auto make_function(SenderFactory algo, Args... args)
  -> function<__result_t<Queries, SenderFactory, Args...>(Args...)>;

[ericniebler]

I'm wondering if GCC's ASAN implementation is mucking with this operator== implementation in some way, like initializing the std::byte make_sender_[sizeof(void *) * 2] member with garbage, or something:

i think you're accidentally comparing padding bits for equality. ex::just is 1 byte, but its value could be anything from 0x00 to 0xFF since the type is empty.

[ispeters]

I'm wondering if GCC's ASAN implementation is mucking with this operator== implementation in some way, like initializing the std::byte make_sender_[sizeof(void *) * 2] member with garbage, or something:

i think you're accidentally comparing padding bits for equality. ex::just is 1 byte, but its value could be anything from 0x00 to 0xFF since the type is empty.

I think you're right. I realized I've assumed that is_trivially_copyable implies "can be compared for equality with memcmp", which is probably not true.

I can see two ways to resolve this:

1. add a function pointer to the implementation that points at an is_equal function that does a type-safe comparison, or
2. follow std::function's example and remove equality-comparableness.

Do you have an opinion on which direction makes more sense?

[ericniebler]

/ok to test 0131a63

[ericniebler]

#2065 #2066 should fix the clang-16 failures.

[ericniebler]

/ok to test 86e74a5

[ispeters]

I've rebased locally onto main; I'm running a Clang 16 build to see if it's fixed.

[ericniebler]

/ok to test 97c753a