@nogc

[Chris Cain via Digitalmars-d]

On Friday, 11 July 2014 at 04:23:20 UTC, Kapps wrote:
> I somewhat remember discussion about this originally during the 
> @nogc discussions. My stance remains that if you're throwing 
> exceptions, you don't care about the semi-realtime requirements 
> that @nogc benefits. Ideally it would be some sort of 
> ref-counted exception, but honestly I think GC exceptions are 
> perfectly okay. If you're concerned whether something might 
> allocate through throwing, you could use nothrow. I get that 
> allowing allocating for throwing exceptions feels 'dirty', but 
> in practice I'd much prefer being able to throw in the 
> extremely rare situation than not be able to mark the method 
> nogc without ugly workarounds. Indeed, the latter would 
> probably bring more allocations than the former.

Frankly, if there were absolutely no possibilities of workaround, 
I could accept it. But there's certainly many ways to accomplish 
this stuff without the GC and it makes it so that you can have a 
more useful `@nogc` that covers more use cases (specifically, the 
use cases of the people phobic of the GC). I'll 100% guarantee 
right now that negative reddit discussions will talk about how 
`@nogc` doesn't really make sure you don't use the GC if we end 
up allowing this. I know it's the "easy" solution, but often the 
"easy" solution won't be the best solution.

Plus there's a *huge* difference between the <1 ms of pause on a 
SINGLE thread that exception handling will incur vs the 3-30ms 
pause on ALL threads that a GC allocation can cause. Just because 
exception handling is pretty expensive in terms of regular 
function calls and such doesn't mean it's completely acceptable 
to give up all reasonable levels of performance. It's not 
black-and-white for most use-cases.

Not to mention some people want threads that don't even have GC 
turned on at all. We'll still need a `@reallynogc` for that 
unless we just want to make it impossible to trust using D 
libraries for that work (again, throwing away all code/manually 
hand-verifying code just because some code isn't applicable for 
working without GC is far too extreme).