On Wednesday, 14 September 2016 at 07:55:24 UTC, John Colvin
wrote:
On Tuesday, 13 September 2016 at 22:28:09 UTC, deadalnix wrote:
On Tuesday, 13 September 2016 at 22:19:54 UTC, Jonathan M
Davis wrote:
The big problem with exceptions being allocated by the GC
isn't really the GC but @nogc.
No the problem IS @nogc . Allocating with the GC is absolutely
not a problem is you deallocate properly. What is a problem is
when you leak (ie, when the ownership is transferred to the
GC). If you don't leak, GC do not kicks in.
Can you explain a bit more here? Do you mean in practice (I.e.
in current implementation) or in theory?
My point is that if you have lifetime information for some data
(and it looks like this is where we want to go with things like
DIP25 and DIP1000, but let's not get lost in the specific of
these proposal now) you know they are going to end up being freed
without the GC having to do a collection cycle.
Therefore, you know you'll not end up having to rely on the GC as
long as you can track lifetime, even if you allocate with it.
Now that this is established it follows that disallowing GC
allocation in @nogc code is needlessly restrictive and promote
unsafe patterns (like allocating using malloc + giving the range
to the GC, which is both slower than allocating on the GC
directly and more error prone).
A more sensible approach is to allow GC allocation in @nogc code
but disallow cases where GC's alloc lifetime cannot be tracked.
Note that this isn't the case for most exceptions.
For instance, when you do
throw new Exception("tagada");
The compiler can deduce that the ownership of the exception is
transferred to the runtime, which will transfers back to the
catch block that gets it. Depending of what this catch block is
doing, it may or may not be @nogc, but there is no reason that
for throw to not be allowed in @nogc code.
However, if you have something like
throw e;
With e a reference to an Exception who's lifetime cannot be
tracked, then it makes sense to disallow it in @nogc code.
TL;DR : The problem is not new, the problem is the rhs of
assignment operations.
