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.
