DIP60: @nogc attribute

[Walter Bright via Digitalmars-d]

On 4/15/2014 12:12 PM, Steven Schveighoffer wrote:
>>> What about syscalls?
>>
>> Not sure what you mean by that, but obviously Windows API functions would be
>> @nogc.
>
> Linux syscalls are not Windows API, they are extern(C) calls. Basically, we will
> have to mark most as @nogc, right?

Right, just like nothrow.


> or are extern(C) calls automatically considered @nogc?

No, just like for nothrow.


> int isthisok(int x, int y) @nogc
> {
>     // need scratch space
>     int[] buf = new int[x * y];
>     scope(exit) GC.free(buf.ptr);
>     // perform some algorithm using buf
>     ...
>     //
>     return buf[$-1];
> }
>
> Valid?

No.


>>> Must you use C malloc/free?
>>
>> If you can GC/GCfree, then you can use malloc/free.
>
> What if you can't use GC/GCfree? i.e. @nogc (the point of this thread)

Then use malloc/free.


>>> What about such code that is @safe, which cannot call free?
>>
>> There's no point to @nogc if you can still call the GC in it.
>
> This is a follow-on to the previous question. Let's say you cannot use GC, but
> clearly, I can use C malloc/free. Safe code that needs arbitrary buffers must
> use C malloc/free to manage them, but safe cannot legally call free.

That's why @trusted exists.


> I think we would need some sort of scoped allocator to make life bearable.

     p = malloc(...);
     scope(exit) free(p);

Let's be clear about the motivation for @nogc - there are a lot of people who 
will not use D because of fear of GC. They want a guarantee that the GC isn't 
being called. They don't want code that hides calls to GC.