| |
 | Posted by Jonathan M Davis |  Permalink Reply |
|
Jonathan M Davis 
| https://issues.dlang.org/show_bug.cgi?id=15100
Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |issues.dlang@jmdavisProg.co
| |m
--- Comment #2 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
Whether it even makes sense for new Error to be @nogc depends on whether the GC is available or not. If it is, then the Error will presumably kill the program, so the allocation isn't a problem. However, if the GC isn't available, and the programmer is relying on @nogc to guarantee that the GC isn't actually used, then there's definitely a problem.
But maybe that can all be cleaned up with the reference counted Object hierarchy that's been talked about previously, since Exceptions and Errors would presumably be part of that - though unless they're malloced, they'd still be using the GC, and presumably, using new wouldn't use malloc, so if we wanted a ref-counted Throwable to be on the malloced heap, something other than new would have to be used.
idup will always use the GC regardless though. I don't see how it could be otherwise. So, even if it were fixed so that Error was ref-counted and malloced, idup still wouldn't work without the GC. We really need some other way to handle the strings for the exception messages if we want to avoid the GC.
This whole situation is a bit sticky though, because we're basically trying to ban the GC in @nogc code while still using for stuff related to exceptions, and that's obviously problematic.
Maybe if allocating for an assertion fails, it should result in a message being printed (if possible) and then a HLT instruction? Even if Errors in general have a problem, stuff like assertions are controlled by druntime where we can have some control over what's going on without requiring a full-blown solution for dealing with the @nogc problem with exceptions. If we absolutely had to, we could use a function pointer to a @nogc function and using casting to make it point to one that isn't actually @nogc, though I really think that we should find a more principled solution to this that doesn't require lying about being @nogc.
Regardless of the exact solution here, I suspect that if we want to fully sort out the various issues with @nogc and exceptions (be they Errors or Exceptions), we need to sort out the ref-counting Object hierarchy stuff and whatever that's supposed to do and look like.
--
|
