What are senders good for, anyway?

IMHO the more abstract and complex a system is, the more chances that something will go wrong. When one has to figure out what's actually happening among a huge mess of overly-abstracted code, simple and straightforward always wins. Perhaps it's some kind of job security.

It turns out those long complex pieces of code are not something the consumer, the program writer, me and you, will ever need to see. If the author reads this, I apologise for saying so, but IMO the blog post aims well but misfires: it needs to communicate to C++ developers what code _they_, ie _us_ normal folk, will see and write. Otherwise we'll get scared off. (But, I do note your absolute enthusiasm shines through and that carried me through the entire post :))

> At this point you may be wondering what’s the point to all of this. Senders and receivers, operation states with fiddly lifetime requirements, connect, start, three different callbacks — who wants to manage all of this? The C API was way simpler. It’s true! So why am I so unreasonably excited about all of this? The caller of async_read_file doesn’t need to care about any of that.

This is in "step 6", about ten screens into the blogpost. Good thing I read the whole thing!

So, THIS is the takeaway. You have old code (C-style, like the Win32 API):

    /// Old-style async C API with a callback
    /// (like Win32's ReadFileEx)
    
    struct overlapped {
      // ...OS internals here...
    };
     
    using overlapped_callback =
      void(int status, int bytes, overlapped* user);
     
    int read_file(FILE*, char* buffer, int bytes,
                  overlapped* user, overlapped_callback* cb);

    exec::task< std::string > process_file( FILE* pfile )
    {
      std::string str;
      str.resize( MAX_BUFFER );
     
      auto [bytes, buff] =
        co_await async_read_file(pfile, str.data(), str.size());
     
      str.resize( bytes );
      co_return str;
    }

> You want to use senders because then you can stitch your async operations together with other operations from other libraries using generic algorithms from still other libraries. And so you can co_await your async operations in coroutines without having to write an additional line of code.

> Why do we need senders when C++ has coroutines? [...] this isn’t an either/or. Senders are part of the coroutine story.

And actually -- that looks pretty good to me!

And if the author reads this, if I may suggest, put this first! (Combined with the note about multiple different APIs all made cohesive, give two examples perhaps.) But sell the solution, then explain the intricate mechanism.

And, great work. I can see myself writing code using this. I like it.

Asio also has its flaws, but the async story in C++ has quite the cognitive overload.