Enforcing basic exception safety is trivial, you just have to follow very simple rules.
Enforcing strong exception safety might require some thought, but it's definitely not "a research-level problem".
In any case either of these is miles easier than satisfying the Rust borrow checker, unless you use the cop-out of (A)rc.
Regardless, how the invariants of your objects are maintained in case of operation failure is something you should be thinking of regardless of the language.
> Enforcing basic exception safety is trivial, you just have to follow very simple rules.
That's not my experience as a C++ developer in a complex, cross-platform, application, which needs to:
1. interact with C;
2. operate with an event loop;
3. operate/interact with a GC;
4. interact with non-trivial system libraries (e.g. Direct3D, Vulkan, ...)
> In any case either of these is miles easier than satisfying the Rust borrow checker, unless you use the cop-out of (A)rc.
The borrow checker is indeed complicated. I'm not sure how you define "satisfying", though. As for (A)rc, it can definitely be interpreted as a "cop-out" or as delaying optimization until you actually have good reasons to believe that you need it.
I'm sorry to hear that you haven't been successful in using C++ features to their full potential in environments tightled coupled with C libraries. Integration with C or C-like code usually requires some effort if you want to be able to use exceptions that could propagate through C.
I do not offer consulting but can refer you to people who do.
Well, from what you were saying, it's mostly a problem of making your asynchronous framework work well with exceptions. It is true that you need to do special things for asynchronous programming to work well in C++, be it for exceptions or even the scope-bound lifetime management of C++ in general, which all have a huge impact on the design of your system.
In particular most multi-threaded C++ code is incorrect, not because it is impossible to do it correctly, but because the standard tooling is too low-level, each third-party framework targets a different niche, and people who roll their own tend to hack it together.
I understand Seastar is supposed to do it somewhat correctly, so you could suggest to Mozilla that they switch to that.
Enforcing strong exception safety might require some thought, but it's definitely not "a research-level problem".
In any case either of these is miles easier than satisfying the Rust borrow checker, unless you use the cop-out of (A)rc.
Regardless, how the invariants of your objects are maintained in case of operation failure is something you should be thinking of regardless of the language.