On Tuesday, 26 July 2016 at 14:51:21 UTC, jmh530 wrote:
On Tuesday, 26 July 2016 at 01:07:27 UTC, Chris Wright wrote:
@nogc conflates "doesn't allocate memory from the GC heap
because I don't want my application to use the GC at all" with
"doesn't cause GC collection pauses".
The latter can have a @assumenogc annotation that works -- you
call GC.disable and GC.enable as appropriate. The former can't.
For whatever reason, I like the idea of annotations behaving
like enums. So instead of @gc or @assumenogc, you could have
something like @nogc.false or @nogc.assume. You wouldn't add
new annotations, just new behavior for existing annotations.
Chris is right that @safe/@trusted is not analogous to
@nogc/@assumenogc, but I still think @assumenogc is a good
idea..or maybe @nogc(false) to offer the opposite behaviour of
@nogc.
There are arguments that can be made against this idea, but IMO,
it's really hard to screw this up unintentionally. It's not like
it's an invisible implicit conversion.
There are plenty of valid use cases. One, like I mentioned, about
strongly deterring allocations in certain contexts instead of
completely disallowing them. Also, deferring garbage collection
until the end of a performance sensitive algorithm that may still
allocate, so that GC.collect can be called manually afterward.
Bit.
