Feature-request: nothrow-connectable any_sender

exec/any_sender_of.hpp と Godbolt の例から始め、次に stdexec::then が any_sender の connectability と completion signatures をどのように処理するかを追跡します。提案されている allocation と fallback のアプローチを比較します。any_sender nothrow-connectable が正しく合成され、allocation-failure の動作を定義する、文書化された API 設計ができれば完了です。

While writing some stdexec-based code, I've come up with this code:

#include <exception> 

#include<exec/any_sender_of.hpp>

using int_sig = stdexec::set_value_t(int);
using exc_sig = stdexec::set_error_t(std::exception_ptr);

using nothrow_int_sender =
    typename exec::any_receiver_ref<stdexec::completion_signatures<int_sig>>::template any_sender<>;

using throwing_int_sender = 
    typename exec::any_receiver_ref<stdexec::completion_signatures<int_sig, exc_sig>>::template any_sender<>;

template<class S>
S mul2(S s) {
    return stdexec::then(std::move(s), [](int x) { return 2*x; });
}

void bar() {
    mul2<throwing_int_sender>; // 1
    mul2<nothrow_int_sender>; // 2
}

(Godbolt link: https://godbolt.org/z/GeE96Wj1n)

The problem is, while (1) compiles as expected, (2) does not compile. As far as I understand, it happens because connect CPO for any_sender is never marked with noexcept. stdexec::then detects that input sender is not nothrow-connectable and returns sender which has exc_sig as one of its completion signatures, so it can not be converted into nothrow_int_sender.

It seems that this problem is very general: one can declare any_sender that does not throw exceptions, but one can't compose it.

I think that new flavour of any_sender where connect is noexcept will be a good addition to this library: non-forcing exceptions for error handling is important, and type-erasing senders is also important (to better hide implementation details, improve compilation times, and other reasons), so combining these two features feels useful too.

In general, nothrow-connectable any_sender seems implementable. I can see two potential sources for exception in connect for a type-erased sender:

1. connect on the underlying sender can throw an exception.
2. When operation object is large enough, library has to allocate memory for it, and this allocation can throw.

Case (1) can be solved by prohibiting senders which are not nothrow-connectable (which totally makes sense).

Case (2) seems more challenging. I can propose several possible solutions:

1. Simply abort on allocation error. It should work well in practice, since on most typical environments allocation itself never returns nullptr.
2. Prohibit senders which are going to create large operation object. This way, connect shouldn't have to allocate memory.
3. Require user to provide some fallback (e.g. function template that, given receiver, must connect it with some other sender and return a small operation).
4. Preallocate operation object storage at construction, and use it during connect. (This allocation also can throw, but it happens inside user code, so user is able to handle it however they want)

Solution (1) is the simplest one, but carefully hidden abort doesn't feel appropriate for a general-purpose library.
Solution (4) is also very simple, but it increases memory usage, which also feels inappropriate.

Solutions (2) seems fine. In particular, user can still put large sender by applying some other adapter which dynamically allocates sender and/or operation object, but does not erase types. Now any allocation error handling, whether it is abort or some careful recovery) becomes concern for that other adapter.

Solution (3) also seems fine. Besides, it is easy for user to provide fallback which just calls std::terminate() and get behavior, equivalent to (1). Alternatively, user can specify a fallback whose instantiations are ill-formed, and get behavior, equivalent to (2).

In my opinion, (3) is simpler, and it's API surface will likely be smaller.

To sum up, user has to do something about memory allocation errors (but it shouldn't be a challenge, as noexcept code already has to do something about allocation errors). Other than that, potential nothrow-any-sender should be as easy-to-use as the current one, and overall it seems like a useful API addition.