Exceptions in @nogc code

[deadalnix via Digitalmars-d]

On Saturday, 1 April 2017 at 13:34:58 UTC, Andrei Alexandrescu 
wrote:
> Walter and I discussed the following promising setup:
>
> Use "throw new scope Exception" from @nogc code. That will 
> cause the exception to be allocated in a special stack-like 
> region.
>
> If the catching code uses "catch (scope Exception obj)", then a 
> reference to the exception thus created will be passed to 
> catch. At the end of the catch block there's no outstanding 
> reference to "obj" so it will be freed. All @nogc code must use 
> this form of catch.
>
> If the catching code uses "catch (Exception obj)", the 
> exception is cloned on the gc heap and then freed.
>
> Finally, if an exception is thrown with "throw new Exception" 
> it can be caught with "catch (scope Exception obj)" by copying 
> the exception from the heap into the special region, and then 
> freeing the exception on the heap.
>
> Such a scheme preserves backward compatibility and leverages 
> the work done on "scope".
>
>
> Andrei

I'll repeat myself, even if I don't believe it'll be listened to 
at this point.

The problem you want to address is not GC allocations, it is GC 
collection cycles. If everything is freed, then there is no GC 
problem. not only this, but this is the only way GC and nogc code 
will interact with each others.

As long as a memory allocation has an owner the compiler can 
track, it can be freed explicitly, and, when it cannot, the 
compiler transfer ownership to the GC, which is illegal in @nogc 
code.

Transfering the ownership to the unwind handler when doing:

throw new FooException();

Is not rocket science and doesn't need any new language addition.

Now onto to scope. Scope essentially means that you are going to 
use some object without taking ownership of it. Indeed, in case 
of catch(Exception e) the language has to transfers the ownership 
of the Exception to the GC, which is the thing that should be 
illegal (not throwing). catch(scope Exception e) would work both 
with GC owned and runtime owned exception, and, because the 
runtime know what's up, it can explicitly free the exception when 
it exit the catch block (there is already a runtime call for 
that), in the case it owns it.

It doesn't need any kind of throw new scope Exception, and was 
proposed, literally, years ago during discussion around DIP25 and 
alike.

I urge you to reconsider the proposal that were made at the time. 
They solve all the problems you are discovering now, and more. 
And, while more complex that DIP25 alone, considering 
DIP25+DIP1000+this thing+the RC object thing, you are already in 
the zone where the "simple" approach is not so simple already.

Things are unfolding exactly as predicted at the time. Ad hoc 
solutions to various problems are proposed one by one and the 
overall complexity is growing much larger than initially proposed 
solutions.