@gc attribute for bypassign @nogc

[bitwise via Digitalmars-d]

On Thursday, 28 July 2016 at 21:07:22 UTC, ag0aep6g wrote:
> On 07/28/2016 10:46 PM, Lodovico Giaretta wrote:
>> Also, the code of that maybe-not- at nogc library may not be 
>> available to
>> check for this thing. Maybe the user doesn't want to trust the 
>> library
>> writer, and so wants the compiler to guarantee no allocations 
>> at all.
>
> If you can't check the code, you have to trust the library 
> writer. One can hack around @nogc as it is. It's not like dmd 
> checks the object file for GC allocations.

Yeah... So on one hand, currently, you could potentially have 
some random hack misbehaving inside @nogc code with no way to 
detect it, whereas a simple search for @assumenogc would 
immediately tell you if the @nogc convention was being broken for 
any reason. On the other hand, adding @assumenogc may increase 
the amount of instances where this is happening, cause this 
search to be mandatory for every package you decide to download.

Maybe if there were 3 variations, this could work:

// use current convention. 100% guarantee, no allocations.
@nogc

// same as current, but restriction can be broken by @nogc(off)
@nogc(weak)

// allows allocations. Can only override @nogc(weak), but not 
@nogc.
@nogc(off)


Example:

class NPC {
	Cake cake;
	void start() {
		cake = new Cake();  // OK
	}
	void update() @nogc(weak) {
		cake = new Cake();     // error: cannot allocate here
		@nogc(off) {
			cake = new Cake();  // ok: alloc allowed in @nogc(off)
		}
	}
	void draw() @nogc {
		@nogc(off) {    // error: @nogc(off) not legal inside @nogc
			cake = new Cake();
		}
		bar(); // error: nogc(weak) not callable here
	}
	void bar() @nogc(weak) { }
}