@nogc

[Kapps via Digitalmars-d]

On Friday, 11 July 2014 at 04:00:05 UTC, Chris Cain wrote:
> On Friday, 11 July 2014 at 03:45:17 UTC, Walter Bright wrote:
>> I've thought of allowing "throw new ...", and yours would be 
>> in addition to that, in @nogc functions, but was waiting to 
>> see how this would play out a bit first.
>
> Errors I agree with (basically, that's the end of your program, 
> so "violating" @nogc is irrelevant in that case). "throw new 
> ..." being allowed in general feels to me like it'll break the 
> entire point of `@nogc` code for many people. `@nogc` was (or, 
> at least I thought it was) designed to stop having people from 
> having to read through implementations of everything their 
> using to verify nothing is using the gc, which was error prone 
> and time consuming. Allowing parts of libraries to throw/get 
> caught somewhere inside of `@nogc` code makes it so you have to 
> go back to manually verifying their not using exception 
> handling somewhere. Sure, it reduces the potential footprint of 
> such, but we're right back to the same old problem again that 
> `@nogc` was supposed to solve. So for people saying "Oh, I want 
> to avoid the GC in D", they'll just complain about how `@nogc` 
> still allows you to hit the GC unintentionally once they find 
> out. Then we'll have requests for `@reallynogc` to be added.
>
> Though, again, I'd be ok with if the thing being newed deriving 
> from Error (if it's being thrown immediately). Theoretically 
> I'd also be OK if the `new` throw could be statically verified 
> to be "caught" outside of `@nogc` code (that is, throwing will 
> throw you outside of `@nogc` code, thereby not technically 
> violating `@nogc`). This sort of reasoning is consistent with 
> Errors being allowed to be newed. However, I think that sort of 
> thing is unlikely to be possible.

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.