Difference between revisions of "DIP60"

From D Wiki
Jump to: navigation, search
m (formatting)
Line 22: Line 22:
|[[DIP60/Archive]] — [https://github.com/D-Programming-Language/dmd/pull/3455 pull request]
|[[DIP60/Archive]] — [https://github.com/D-Programming-Language/dmd/pull/3455 pull request] [http://forum.dlang.org/post/lijoli$2jma$1@digitalmars.com forum discussion]
- [http://forum.dlang.org/post/lijoli$2jma$1@digitalmars.com forum discussion]

Revision as of 11:52, 18 April 2014

Title: DIP Add @nogc Function Attribute
DIP: 60
Version: 1.2
Status: Draft
Created: 2014-4-15
Last Modified: 2014-4-18
Author: Walter Bright
Links: DIP60/Archivepull requestforum discussion


The @nogc function attribute will mark a function as not making any allocations using the GC.


Many users want to be able to guarantee that code will not allocate using the GC.


@nogc goes in the same way that the nothrow attribute does, and is quite similar in behavior. It affects inheritance in that it is covariant. The name mangling for it will be "Ni". @nogc will be inferred for template functions in the same manner as nothrow is. @nogc will be transitive, in that all functions called by an @nogc function must also be @nogc. GC allocations in a @nogc function will be disallowed, and that means calls to operator new, closures that allocate on the GC, array concatenation, array appends, and some array literals.

No functions in the GC implementation will be marked @nogc.


@nogc int func(int a) { ... }

Static allocations should be ignored

This code (and its mutable __gshared variants) should work since the beginning:

 void foo() @nogc nothrow {
     static const err = new Error("error");
     throw err;

The situation is similar to this code, that is allowed (text is not nothrow, but here it's called at compile-time):

   void foo() nothrow {
       import std.conv;
       enum msg = text(10);

Behaviour in presence of optimizations

Using Escape Analysis the LDC2 compiler is able to remove the heap allocation from this main function when full optimizations are used. However, validity of code should not be affected by optimization settings. (Nor can it be, without intertwining the compiler frontend with each backend in rather complicated ways.) Hence the following main function cannot be annotated with @nogc even when Escape Analysis removes the heap allocation:

   __gshared int x = 5;
   int main() {
       int[] a = [x, x + 10, x * x];
       return a[0] + a[1] + a[2];


This document has been placed in the Public Domain.