@gc attribute for bypassign @nogc

[bitwise via Digitalmars-d]

On Thursday, 28 July 2016 at 16:58:14 UTC, default0 wrote:
> On Thursday, 28 July 2016 at 16:45:05 UTC, bitwise wrote:
>> On Thursday, 28 July 2016 at 16:15:04 UTC, Guillaume Piolat 
>> wrote:
>>> On Thursday, 28 July 2016 at 15:24:10 UTC, bitwise wrote:
>>>>
>>>> It's not about running out of memory. It's a performance 
>>>> issue.
>>>>
>>>> Example: In the following class, it would be perfectly fine, 
>>>> and even expected to allocate in start() but not in 
>>>> update(). This is because start() gets called once on object 
>>>> initialization, but update() would get called every frame.
>>>>
>>>
>>> Vladimir implemented counting in -profile=gc, it gives you 
>>> the number of allocations and the amount allocated for each 
>>> allocation point.
>>
>> I'm not sure if this point is meant to be for or against what 
>> I'm suggesting, but still, I'm thinking in terms of 
>> *proactively* writing efficient code, not allowing an app get 
>> to the point where you need to run a profiler.
>>
>> The situation is similar to using @safe. You *could* just 
>> write code however you want, wait until it crashes, then try 
>> to find the problem using Valgrind or something, but that's 
>> bad for obvious reasons.
>>
>>     Bit
>
> Just my 2 cents on naming: what you want sounds a lot more like 
> @warngc than @assumenogc or whatever was floating around 
> before. What such an attribute should do and if its worth 
> implementing is hard to figure out, though. Presumably you'd 
> have your update() method marked @warngc but then how is the 
> compiler supposed to know that an allocation like this:
>
> class A {
>     void update() @warngc {
>         if(rareCondition()) {
>             // something that allocates
>         }
>     }
> }
>
> is perfectly fine, but something like this
>
> class B {
>     void update() @warngc {
>         if(almostAlwaysTrue()) {
>             // something that allocates
>         }
>     }
> }
>
> is not?
> That issue aside, what exactly do you envision the compiler to 
> tell you (examples of error messages and code patterns it 
> should detect, examples of code patterns that it should NOT 
> detect and are fine) incase it automagically finds problematic 
> code?
>
> I'm having trouble putting a thumb on what you want following 
> this thread, because what you are describing feels a bit vague 
> to me.

I think you're complicating the issue quite a bit here.

It's very simple:

@nogc { /* in this scope, compiler disallows GC allocations. */ }

@nogc {
     @assumenogc { /* here, GC allocations are allowed */  }
}

@assumenogc would simply reverse the effects of the @nogc flag on 
a given scope.

So @nogc could be applied to performance critical scopes, as it 
is now. The exception would be, that if I as a programmer knew 
that I was only making a small one-time allocation, and that the 
GC was still enabled, I could do so by surrounding the allocation 
with @assumenogc.

     Bit