DIP60: @nogc attribute

[Dicebot via Digitalmars-d]

On Saturday, 19 April 2014 at 18:12:32 UTC, Ola Fosheim Grøstad 
wrote:
> On Saturday, 19 April 2014 at 18:05:48 UTC, Dicebot wrote:
>> In lot of standard library functions you may actually need to 
>> allocate as part of algorithm, strict @nogc is not applicable 
>> there. However, it is still extremely useful that no _hidden_ 
>> allocations happen outside of weel-defined user API and this 
>> is something that less restrictive version of @nogc could help 
>> with.
>
> What you want is to mark some functions with @allow_gc ? So 
> that you only get GC where specified as a "contract"?
>
> But isn't this more suitable for dynamic tracing/logging?
>
> Because what you want is probably the frequency of GC 
> allocations in a particular call tree?

Original proposal, updated and re-worded as formal as possible.

"weak @nogc" functions / methods are identical to normal @nogc 
function but are allowed to trigger GC via functions / methods 
directly accessible via its arguments. Such weak @nogc functions 
can only call strict @nogc functions in any other context.

Exact details get tricky rather quick and this is something that 
needs thorough examination but rationale behind this is to move 
all allocation decisions exclusively to caller side. Frequency 
does not matter here, only the fact that function does not cause 
allocations of its own.

Again, example of a pattern that should be common in Phobos:

void foo(ref OutputBuffer buffer) @nogc
{
     buffer.put(42); // buffer.put may be not @nogc, this turns 
foo into "weak @nogc"
     throw new Exception(); // put this is prohibited anyway
     someGCFunction(); // as well as this..
     int[] arr; arr ~= 42; // ..and this
}

User of such functions will be 100% sure that if any allocations 
happen, he is the one to blame and can tweak it in his own code, 
possibly using OutputBuffer implementation that does not use GC 
or allocations at all.