Good luck!

Kind of.

You still need a runtime library, which should be integrated by C++23, lets see.

What C++ has better than Rust on this regard is that C++20 at least shipped at the necessary vocabulary types and compiler magic, so the plug-and-play story across runtimes (HPX, C++/WinRT, kokos,....) is much more sound today.

Only to a certain extent. The question is not only if something is possible, but also what the most convenient way to express it is. Effect handlers do have some interesting ideas for programmer-level interface, like user-defined typed commands and dynamic pairing of commands with handlers. In this sense, C++20 coroutines or Boost Context are lower-level, and maybe not the most convenient building blocks for implementing complicated concurrency scenarios, yet alone effects that do not look like concurrency at first sight, like exceptions or different forms of mutable state.

This uses stackful continuations. I.e. you can nest arbitrary code between setting the handler and invoking an effect. With C++ language-level coroutines, everything in between would also need to be a coroutine which doesn't compose as well (i.e. this library doesn't suffer from the colored function problem).

You mean threading? That is just one common example for what is possible with arbitrary effect handlers.

Well... it is the best form I could come up with. My interest regarding this project is mostly in usable programmer-level abstractions, so I am very open to any ideas of what kind of API would be better. I'd be super-happy to discuss any alternatives.

Background: In this implementation the use of inheritance is not just for the sake of it ("because it's C++"), but because it gives me type-safety. When you program with handlers, there are a lot of types floating around (the type of the handled computation, the answer type of the handler, the return types of the commands), and I want the compiler to keep track of those. The best option I could find is to make handlers classes that derive from an abstract template, which forces the handler to have the appropriate command/return clauses with appropriate types.

Folks familiar with effect handlers in functional programming might be suspicious about handlers living on two levels, as they are defined as classes but then you handle a computation with a particular object of that class. But it is not a new idea (cf. Pablo Inostroza, T. Storm "JEff: objects for effect"), and this is a much more natural way to express stateful handlers than parameterised handlers in FP.