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.