@gc attribute for bypassign @nogc

[Danni Coy via Digitalmars-d]

I am not convinced this is the best way to go although it would be a
relatively easy solution.

What I would personally prefer was if there was a language mechanism
to mark theAllocator, processAllocator (iAllocator) to be @nogc as
long as the allocator in question is not the GCAllocator.

I am thinking specifically of the situation where vendor A can create
a dynamic library in D that uses theAllocator and vendor B uses that
library without necessarily having the source code.


On Wed, Jul 27, 2016 at 7:05 AM, bitwise via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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.
>