DIP 1008 Preliminary Review Round 1

[Steven Schveighoffer via Digitalmars-d]

On 5/19/17 11:45 AM, Mike Parker wrote:
> DIP 1008 is titled "Exceptions and @nogc".
>
> https://github.com/dlang/DIPs/blob/master/DIPs/DIP1008.md
>
> All review-related feedback on and discussion of the DIP should occur in
> this thread. The review period will end at 11:59 PM ET on June 2 (3:59
> AM GMT June 3), or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP
> will be scheduled for another round. Otherwise, it will be queued for
> the formal review and evaluation by the language authors.
>
> Extensive discussion of this DIP has already taken place in two threads,
> both linked from the document. You may find it beneficial to skim
> through those threads before posting any feedback here.
>
> Thanks in advance to all who participate.
>
> Destroy!

Some comments:

"The destructor for Throwable will, if the refcount is 1, call 
_d_delThrowable(e.next), i.e. on the head of the chained list of 
exceptions."

How does this work if the throwable is being destroyed by the GC? In 
this case, e.next may be a dangling pointer.

"it will call the new function _d_newThrowable() which will allocate E 
and intialize it for refcounting."

Where is it allocated? If on the GC heap, how can it be @nogc? If not, 
then how does it interact with GC pointers? e.g. the e.next pointer may 
point to a GC-allocated exception, how to stop the GC from collecting it 
early?

Part of this may mean clarifying what @nogc actually means. Does it mean 
no interaction with the GC system, or does it mean "cannot run a 
collection cycle"?

"In catch blocks, e is regarded as scope so that it cannot escape the 
catch block."

If e is scope, then the destructor is called. However, since e is a 
reference type, the data it points at isn't really stack allocated, and 
the scope-ness ends at the reference, no? So what if you have something 
like this?

void *foo;

try
{
   func();
}
catch(MyException e)
{
    foo = e.voidptr; // get pointer to some member
}

Should foo be allowed to capture pieces of e? How does the compiler stop 
that if not? What expectations can e assume in terms of its members that 
are references? Can it assume that it is in charge of the management of 
that memory if it's ref counted, or does it need to assume GC usage for 
those items?

-Steve