@gc attribute for bypassign @nogc

bitwise via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 26 14:05:34 PDT 2016


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.



More information about the Digitalmars-d mailing list