Is there a proposal for how D will support throwing Exceptions in @nogc code in the future?  I've searched the forums and found different proposals that involve things like pre-allocated exceptions, non-gc heap allocated exceptions or even stack allocated exceptions.  I don't want to debate the details of each solution, I'd just like to know if any of these proposals are deemed a "good idea", or if any of them are currently being worked on.  I personally think that using non-gc heap allocated exceptions in combination with the new scope semantics would be a great solution in many cases, but I don't know if there is any consensus or if this topic is just on the back-burner. Thanks.

I was wondering the same myself. I think there would be a lot of negative side effects to using alternate memory model other than GC (non-gc could introduce leaks, on stack has potential to be overwritten). For that reason, I think the only choices that make sense are that either @nogc functions are also nothrow, or that phobos has a set of preallocated immutable exceptions that can can thrown.

I personally think that @nogc should be relaxed to exclude allocating exceptions since there would be no gc allocation other than for exceptional situations. I suspect that having code that relies on exception for main case logic is far worse for performance than any gc overhead anyway and is a pattern everyone knows to avoid.

On Tuesday, 17 February 2015 at 05:52:23 UTC, philippecp wrote:
> I was wondering the same myself. I think there would be a lot of negative side effects to using alternate memory model other than GC (non-gc could introduce leaks, on stack has potential to be overwritten). For that reason, I think the only choices that make sense are that either @nogc functions are also nothrow, or that phobos has a set of preallocated immutable exceptions that can can thrown.
>
> I personally think that @nogc should be relaxed to exclude allocating exceptions since there would be no gc allocation other than for exceptional situations. I suspect that having code that relies on exception for main case logic is far worse for performance than any gc overhead anyway and is a pattern everyone knows to avoid.

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.

On Monday, 16 February 2015 at 23:17:03 UTC, Jonathan Marler wrote:
> Is there a proposal for how D will support throwing Exceptions in @nogc code in the future?  I've searched the forums and found different proposals that involve things like pre-allocated exceptions, non-gc heap allocated exceptions or even stack allocated exceptions.  I don't want to debate the details of each solution, I'd just like to know if any of these proposals are deemed a "good idea", or if any of them are currently being worked on.  I personally think that using non-gc heap allocated exceptions in combination with the new scope semantics would be a great solution in many cases, but I don't know if there is any consensus or if this topic is just on the back-burner. Thanks.

Would RefCounted!T being @nogc help alleviate this issue?

On Tuesday, 17 February 2015 at 07:28:03 UTC, weaselcat wrote:
> Would RefCounted!T being @nogc help alleviate this issue?

I've heard of RefCounted and I understand the concept but I've never used it.  I'll do some reading a some experiments. Maybe this will work :)

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).

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.

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.

On 2/16/15 3:17 PM, Jonathan Marler wrote:
> Is there a proposal for how D will support throwing Exceptions in @nogc
> code in the future?

Nothing definite. We will get on to that right after 2.067. This is a good time to start discussions. -- Andrei

On 17/02/2015 07:28, weaselcat wrote:
> Would RefCounted!T being @nogc help alleviate this issue?

I think Andrei once said that was a good solution for exceptions.

I think the stumbling block is that if T contains indirections, RefCounted calls GC.addRange on the T*, which currently violates @nogc. Perhaps addRange should be allowed even with @nogc, as it doesn't trigger collections as of itself.

Otherwise, we would need some way of controlling whether addRange should be called by smart pointers or not.