Re: 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"