Plan for Exceptions and @nogc?

[Jonathan Marler via Digitalmars-d]

On Tuesday, 17 February 2015 at 21:30:00 UTC, Matthias Bentrup 
wrote:
> On Tuesday, 17 February 2015 at 20:48:07 UTC, Jonathan Marler 
> wrote:
>> That would work if you didn't have to unwind the stack but 
>> unfortunately you do.  The catch block exists in the context 
>> of the function it is written in.  That means it assumes the 
>> stack pointer and stack variables are all in the context of 
>> it's defining function.  If you executed the catch code when 
>> the stack wasn't unwound, then it wouldn't know where any of 
>> the variables were.  Does that make sense?  Think about it for 
>> a minute.  You proposal suggests that the catch code can be 
>> executed no matter how many child functions have been added to 
>> the stack.  This is impossible since the catch code no longer 
>> knows where all of it's stack variables are.  Normally it uses 
>> an offset to the stack pointer but now it has been changed.  
>> That's why you have to unwind the stack.
>
> So the catcher would have to behave like a delegate.

Sure but then you're allocating GC memory again (compounding the 
problem you're trying to solve in the first place).  The best 
solution I can think of that should work in almost every case is 
to allocate the exception on the non-GC heap, then make the 
catcher cleans up the exception.  Simple, and makes sense when 
you think about the lifetime of an exception.  This would have 
been dangerous before but with the new scope semantics D can 
ensure that the exception does not escape the catch block (and 
therefore gets cleaned up properly).