Plan for Exceptions and @nogc?

Matthias Bentrup via Digitalmars-d digitalmars-d at puremagic.com
Tue Feb 17 05:32:39 PST 2015


On Tuesday, 17 February 2015 at 12:41:51 UTC, Marc Schütz wrote:
> On Tuesday, 17 February 2015 at 09:19:55 UTC, Tobias Pankrath 
> wrote:
>> On Tuesday, 17 February 2015 at 07:24:43 UTC, Jonathan Marler 
>> wrote:
>>>
>>> Relaxing the definition of @nogc to exclude exceptions could 
>>> be an acceptable compromise.  However, the nature of an 
>>> exception is that it is allocated when it is created, and 
>>> deallocated after it is caught.  This model fits nicely with 
>>> scope semantics.  The code catching the exception would catch 
>>> a "scoped" reference which means it would be responsible for 
>>> cleaning up the exception.  It would still be allocated on 
>>> the heap, but it wouldn't be GC memory.  This is how I think 
>>> exceptions should have been implemented in the first place, 
>>> but back then the GC wasn't a big deal and scope didn't exist 
>>> yet.
>>
>> This actually puts scope on the head. It's unique / ownership 
>> you're looking for (if at all).
>
> Right. But `scope` still has a place in it. It would either be 
> necessary to allow throwing and catching the unique/owned types 
> (instead of `Throwable`), but that would be quite a change to 
> the language. Or the runtime manages the exceptions (freeing 
> them as soon as they are no longer needed). In that case, the 
> exceptions must not leave the `catch` blocks, which is what 
> `scope` guarantees.

Maybe it is possible to have a separate ScopedThrowable exception 
class.

Those exceptions would be allocated on the stack and would be 
allowed to carry references to local/scoped data, but they live 
only for the duration of the corresponding exception handler.

The compiler should check that the exception and its payload 
don't escape the catch block, and of course the exception handler 
has to run before the stack unwinding is done.

The whole point is of course that ScopedThrowables could be 
thrown from @nogc functions.


More information about the Digitalmars-d mailing list