Plan for Exceptions and @nogc?

[via Digitalmars-d]

On Wednesday, 18 February 2015 at 00:54:37 UTC, Chris Williams 
wrote:
> I didn't mean it as a solution. As said, I was just looking for 
> an intro to the topic, so that I (and others) could 
> meaningfully contribute or at least understand the options. 
> I'll look up libunwind and, if that has enough info for me to 
> grok it, create a wiki page on the subject.

It is a horrible solution developed for the Itanium VLIW 
architecture which is very sensitive to branching. IRRC it 
basically works by looking at the return address on the stack, 
then picking up stack frame information in a global table to 
unwind. It is language agnostic and the language provides a 
"personality function" to unwind correctly in a language 
dependent manner...

AFAIK, C++ exceptions are copied from the stack to a special 
memory region when unwinding to prevent the memory issues D 
suffers from.

I agree that a fast unwind with stack pointer reset or multiple 
return paths would be much better, but you need to rewrite the 
backend to support it. That's the main issue... the "fast path" 
argument is just a sorry excuse that literally means that 
exceptions are avoided for common failures in C++. As a result 
you get APIs that are nonuniform.