Exceptions in @nogc code

[Adam D. Ruppe via Digitalmars-d]

On Saturday, 1 April 2017 at 14:54:21 UTC, deadalnix wrote:
> The problem you want to address is not GC allocations, it is GC 
> collection cycles. If everything is freed, then there is no GC 
> problem. not only this, but this is the only way GC and nogc 
> code will interact with each others.

Amen. Moreover, for little things like exceptions, you can 
probably also just hack it to not do a collection cycle when 
allocating them.

pseudocode:

So right now, we have:

void* gc_alloc(T)(size_t sz) {
     auto alloc = malloc(sz);
     if(alloc is null) {
        collection_cycle();
        retry();
        if(alloc is null) // still
           onOutOfMemoryError();
     }
     return alloc;
}

But imagine if it was

     if(alloc is null && !is(T : Throwable))


so it just abort()'s if it can't allocate the exception instead 
of collecting. How would that be any different than malloc()'ing 
it?

But, if you DO get a chance to run the GC, it will be collected, 
and, of course, you can manually/automatically free it too.

Works with existing code with no more likelyhood of leaking than 
we already have, maintaining memory safety... and removes the 
risk of a new exception of triggering a gc cycle.

so why not?

> Things are unfolding exactly as predicted at the time. Ad hoc 
> solutions to various problems are proposed one by one and the 
> overall complexity is growing much larger than initially 
> proposed solutions.

Yeah, my gut reaction to this was "gross moar attributes come on"