This proposal is sort of based on herbceptions [1]: > Sutter [19] has only very recently proposed re-using the existing function return mechanism in place of t

This proposal is sort of based on herbceptions [1]: > Sutter [19] has only very recently proposed re-using the existing function return mechanism in place of the traditional stack unwinding approaches, requiring no additional data or instructions to be stored, and little to no overhead in unwinding the stack. Furthermore, by removing stack unwinding’s runtime reliance on tables encoded in the program binary itself, the issue of time and spatial determinism is solved. As it is possible to determine the worst-case execution times for programs not using exceptions, it follows that exception implementations making use of the same return mechanism must also be deterministic in stack unwinding. > Given these clear advantages, we have based our implementation on this design, with a core difference being the replacement of their use of registers with function parameters, allowing for much easier interoperability with C code, which can simply provide the parameter as necessary. > A limitation with [19] is that they require all exceptions be of the same type, leaving much of the standard exception-handling functionality up to the user. Our novel approach includes a method of throwing and catching exceptions of arbitrary types (as with existing exception handling), without imposing any meaningful execution-time penalties when exceptions do not occur. At least, it uses a comparable implementation strategy. Herbceptions used a different surface syntax, adding a new kind of exception and a new way to declare them. I rather like that herbceptions are more restricted in type. Restricting the type means that a programmer catching an exception has more things they can do with it. It's currently impossible to sensibly handle exceptions of unknown type in C++. The change is an improvement, not a limitation. The point about interoperation with C is interesting. How would that work? If you wanted to call a C++ function from C, would you have to kludge the prototype to add the exception pointer? The herbceptions paper proposed trying to get the C ABI changed to support the same exception mechanism: > 4.6.11 Wouldn’t it be good to coordinate this ABI extension with C (WG14)? > Yes, and that is in progress. This paper proposes extending the C++ ABI with essentially an extended calling convention. Review feedback has pointed out that we have an even broader opportunity here to do something that helps C callers of C++ code, and helps C/C++ compatibility, if C were to pursue a compatible extension. One result would be the ability to throw exceptions from C++→C→C++ while being type-accurate (the exception’s type is preserved) and correct (C code can respond correctly because it understands it is an error, even if it may not understand the error’s type). [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070...