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
