With all the changes in C++, it always makes me wonder how developers these days reason about what the code is actually going to compile to and perform like. I feel like I have a good enough understanding of C and of older C++, but there's a constant influx of new syntax and new concepts in C++, and for a language that is supposed to be for systems programming, much of that seems so far away from "the machine".

The essence of the sender/receiver proposal is essentially this: - first start with a sync function

      result_t foo(params_t);
      ...
      auto result = foo(params);

- make it async by adding a continuation:

      void async_foo(params_t params, invokable<result_t> cont) { cont(foo(params)); };
      ...
      invokable<result_t> auot receiver= [](result_t result) {...};
      async_foo(params, receiver);

- then curry it:

      auto curried_async_foo(params_t params) { 
        return [params](invokable<result_t> cont) { 
           async_foo(params, cont);
        };}
      ...
      auto op = curried_async_foo(params);
      op(receiver);

- finally modify the curried variant to add another required evaluation round:

      auto foo_sender(param_t params) {
        return [params](invokable<result_t> cont)  {
           return [params, cont]{ 
              async_foo(params, cont);
        };};}
      ...
      auto sender = foo_sender(params);
      auto operation = sender(receiver);
      operation();

The actual library uses structures with named methods instead of callables (so you would do operation.start() for example), plus a separate continuation for the error path (by having the receiver concept implement two named functions), and cancellation support. Also the final operation is required to be address stable until it is completed.

The complexity is of course in the details, and I didn't fully appreciate it until I tried to implement a stripped down version of the model (and I'm sure I'm still missing a lot).

The model does work very well with coroutines and can avoid or defer a lot of the expected memory allocations of async operations.

At the end they mention this text:

The authors and NVIDIA do not guarantee that this code is fit for any purpose whatsoever.

And say that it worries them. This is actually a warranty disclaimer (the warranty of fitness for a particular purpose) and has to be written like this to be effective. So I would not read anything into it

Is it just me or are the code examples of the executors absolutely unreadable/comprehensible without reading it 5 times?

Even with different formatters I'd much prefer the tbb variant.

C++ has two ways of naming things: `std::incomprehensible_long_name` and `|`.