DIP18: Non-GC threads

[Piotr Szturmaj]

bearophile wrote:
> Piotr Szturmaj:
>
>> This is done by adding nogc attribute for functions. nogc functions
>> cannot perform operations that may allocate garbage collected memory.
>
> I suggest to call that @nogc.
>
> Time ago I have suggested a "@noheap" attribute for functions, that is
> similar to that "nogc", see the discussion there:
> http://d.puremagic.com/issues/show_bug.cgi?id=5219

Thanks, I didn't know that. There are some good arguments for @nogc.

> The difference is that @noheap disallows C functions like C malloc(),
> etc. Stack allocation like alloca() and variable length arrays is
> allowed in @noheap functions.
>
> @noheap/@nogc is probably inferred for templated functions, as
> pure/nothrow.

I would prefer @nogc, because nogc functions can manually allocate. Not 
using malloc, or preallocating using it is a lot easier than checking 
for GC allocations and manually managing non-gc threads.

The main reason under @nogc is not non-deterministic allocation of GC or 
malloc. The whole idea is to guarantee that nogc threads are not 
suspended by the GC.

> The main disadvantage of an annotation like this is the proliferation of
> kinds of functions. The advantage is a more precise control of the
> effects of functions.

The advantage is that you'd get the static checks similar to nothrow and 
pure.

> The Koka language has a function annotation similar to @noheap, I have
> discussed a little about Koka here:
> http://forum.dlang.org/thread/ocxmiolhlcysehbjtcop@forum.dlang.org
> but Koka has type inference for effects, so often you don't need to add
> that annotation to functions.

Well, __traits(hasGCallocations, func) will also do the trick.