stdexec VS papers

I searched for more information, and here are some relevant links, in case anybody else is interested: * https://www.reddit.com/r/cpp/comments/zdogz9/new_c_sender_library_enables_portable_asynchrony/ * https://github.com/nvidia/stdexec * https://www.reddit.com/r/cpp/comments/10b76e3/stdexecution_from_the_metal_up_paul_bendixen/ * https://www.reddit.com/r/cpp/comments/st9bjm/p2300_senderreceiver_is_dead_in_the_water_for_c23/

The last direct news about the status of P2547R1 that I'm aware of was with the Soursop and Ponies in Kona blogpost in November 22. r/cpp looks to not have discussed CPOs directly when the post was linked. Indirectly, this Github issue hints that there is a strong possibility of no language alternative available by C++26.

Coroutine task types and other awaitables are well supported by the P2300 std::execution proposal. Take a look at https://github.com/NVIDIA/stdexec Coroutines in general are good at suspension and resumption, but they need a place to run and something to resume them. That's what the sender/receiver framework provides.

Looking for a Study Partner (for SERIOUS learning), in the fields of Robotics | Accelerated Computing.I am studying Electrical Engineering (5 out of 7 semesters) and live in Germany. But yeah, College sucks and I mostly use online resources like NVIDIA's DLI, Coursera, edX, Educative and O'Reilly. [I really don't understand how these aren't the new Universities/Colleges. All I know I learned either from there or Youtube, Udemy or Books. College is actually what is slowing me down. It's such a waste of my time and resources. I asked ONE thing from them, and still, that was too much. They didn't do it.Anyway...I am currently going through/finally sorting out some Data Structures and Algorithms stuff (specially Graphs) and my plans/next goals are 1 - Go through C++'s P2300 Proposal and try to understand it along with NVIDIA's stdexec implementation, 2 - Take NVIDIA's CUDA C++ Course, 3 - Get started with Computer Vision [probably using NVIDIA again haha, along with OpenCV)

Libunifex inspired P2300, but the design of P2300 has evolved since then and libunifex has not kept pace. stdexec is a faithful and up-to-date implementation of P2300. It also adds GPU support and a small number of schedulers and utilities not in P2300.

It is on Github, btw: https://github.com/brycelelbach/wg21_p2300_std_execution

I can't really argue that composing algorithms either using function call or pipe syntax is more readable than coroutines. I'll say this: right now P2300 is missing some discussion of how senders can be made trivially awaitable in a coroutine (and awaitables are senders by definition). If coroutines are your preferred syntax, sender/receiver is still a sound basis. Those parts of P2300 are currently under code review. You can find the PRs here.

What's fun is, because everything is decided in papers, we can find out why! https://github.com/cplusplus/papers/issues/884

Accepted paper here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20...

> The proposed std::print function improves usability, avoids allocating a temporary std::string object and calling operator<< which performs formatted I/O on text that is already formatted. The number of function calls is reduced to one which, together with std::vformat-like type erasure, results in much smaller binary code (see § 13 Binary code).

Additionally,

> Another problem is formatting of Unicode text:

> std::cout << "Привет, κόσμος!";

> If the source and execution encoding is UTF-8 this will produce the expected output on most GNU/Linux and macOS systems. Unfortunately on Windows it is almost guaranteed to produce mojibake despite the fact that the system is fully capable of printing Unicode

See https://github.com/cplusplus/papers/issues/557

Bringing editions to C++ failed, and I am not aware of anyone trying to tackle the issues https://github.com/cplusplus/papers/issues/631

(I could be wrong though! I follow the committee more than you may guess, but not as much as to think I know everything about what's going on.)

GitHub would not be relevant in this respect because:

* It's owned by a (single) commercial corporation, Microsoft.

* There is censorship both by content and in some respects by country of origin.

* The code is closed.

but otherwise it's an interesting idea.

The C++ standardization committee uses GitHub to track papers submitted to them, see:

https://github.com/cplusplus/papers

There was no non-approval. The facility needs more work, and the authors (and the committee) were focusing on getting print/format done first. I hope that the paper will be worked on again in the future. We will be happy to review it once there is a revision (see github for history)

For more details on what we did at the 2023-06 Varna meeting, the [GitHub issue](https://github.com/cplusplus/papers/issues/328) associated with the paper has a summary.

You subscribe to the Github issue of the proposal: https://github.com/cplusplus/papers/issues