@nogc

[Chris Cain via Digitalmars-d]

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.