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()>.