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-@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) { }
}
