Plan for Exceptions and @nogc?

[Jonathan Marler via Digitalmars-d]

On Tuesday, 17 February 2015 at 18:40:51 UTC, Matthias Bentrup 
wrote:
> On Tuesday, 17 February 2015 at 18:30:24 UTC, Jonathan Marler 
> wrote:
>> I thought of the same thing but then realized that it would be 
>> impossible to ensure that the catch block wouldn't stomp on 
>> that memory.
>
> The catcher wouldn't stomp any more on the thrower's memory 
> than a function stomps on the memory of its caller. All the 
> data of the thrower is safe, because it is above the stack 
> pointer. The unwinding hasn't been done at that point.

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.

I like that you thought of this idea but you have to follow 
through with the details to see whether or not it would work.  I 
immediately thought of this idea and then realized that it was 
impossible.  A variation on the idea might work, but the idea as 
it is does not.  Keep thinking about it though...if nothing else 
it will give you a better understanding of the stack.  The more 
people that are intimate with the inner workings of how these 
things work the better.