Exceptions in @nogc code

[Walter Bright via Digitalmars-d]

On 4/2/2017 10:21 AM, Andrei Alexandrescu wrote:
> Such is not possible with a scoped catch. Of course, that's a concern only if we
> want to preserve backwards compatibility.

That can be done if the user makes a clone of 'e' (I don't propose the compiler 
do this automatically).


>> In turn I don't see what adding "scope" to the catch site accomplishes -
>> you still need to ensure the reference doesn't escape.
>
> You don't. Old code behaves as it always did.
>
>> And if it doesn't
>> escape you may just as well deallocate the exception object.
>
> Ah, so here we're looking at a deduction scheme. Most interesting! First try to
> see if "scope" would work (even if not written), and if so just consider it there.
>
>>> Such a scheme preserves backward compatibility and leverages the work
>>> done on "scope".
>>
>> Pardon but I don't see how.
>
> Think again - checks and e.g. deduction (if we add it as you suggested above)
> would work pretty much out of the box.

The compiler can definitely deduce the 'scope' for the catch object, and if it 
is, insert code to free it at the close of the catch. But that has problems:

1. If the thrown object was not allocated with the GC (such as if it was 
'emplaced'), then doing a GC free on it at the catch site will corrupt memory.

2. There isn't an indication to the user if it is free'd or not at the close of 
the catch.

3. The GC code still has to be linked in.

4. The throw site still cannot be marked as @nogc.