iPhone vs Android

[deadalnix via Digitalmars-d]

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.