nothrow by default

[Ola Fosheim Grøstad]

On Sunday, 5 January 2020 at 13:12:47 UTC, rikki cattermole wrote:
> The way this delegate get used is that it gets matched bottom 
> up (like we do now), in the thrower. The throw statement will 
> match the delegate to the exception, call the delegate and then 
> proceed to do whatever that function tells it to do. It could 
> assert out, return Return.init, continue doing stuff (which may 
> lead to asserting out), or unroll to the handling point (which 
> is what we want to avoid).

When exceptions were discussed in the 80s/90s people looked at 
recovery that kinda works they way you describe. So when a 
function fails it can stop and then let some other unit fix the 
problem and then resume where it halted.

I guess you could do this with coroutines in some elegant fashion.

The problem is really writing the code in a recoverable fashion, 
which most programmers seem to not be able to do, hence the 
current "transactional" model of unrolling and the retrying from 
scratch.

With transactional memory and perhaps even a more generic 
transactional concept that also covers external resources then 
you could have complete unrolling without programmer intervention 
(so that no RAII/destructors have to be written). But that is 
rather advanced... and more like research topic I guess.