DIP60: @nogc attribute

[John Colvin via Digitalmars-d]

On Thursday, 17 April 2014 at 19:51:38 UTC, Walter Bright wrote:
> On 4/17/2014 10:41 AM, Dicebot wrote:
>> On Thursday, 17 April 2014 at 16:57:32 UTC, Walter Bright 
>> wrote:
>>>> With current limitations @nogc is only useful to verify that 
>>>> embedded code which
>>>> does not have GC at all does not use any GC-triggering 
>>>> language features before
>>>> it comes to weird linker errors / rt-asserts. But that does 
>>>> not work good either
>>>> because of next problem:
>>>
>>> Remember that @nogc will be inferred for template functions. 
>>> That means that
>>> whether it is @nogc or not will depend on its arguments being 
>>> @nogc, which is
>>> just what is needed.
>>
>> No, it looks like I have stated that very wrong because 
>> everyone understood it
>> in completely opposite way. What I mean is that `put()` is NOT 
>> @nogc and it
>> still should work. Same as weakly pure is kind of pure but 
>> allowed to mutate its
>> arguments, proposed "weakly @nogc" can only call GC via 
>> functions directly
>> accessible from its arguments.
>
> I don't see value for this behavior.

It's a formal promise that the function won't do any GC work 
*itself*, only indirectly if you pass it something that 
implicitly does heap allocation.

E.g. you can implement some complicated function foo that writes 
to a user-provided output range and guarantee that all GC usage 
is in the control of the caller and his output range.

The advantage of having this as language instead of documentation 
is the turtles-all-the-way-down principle: if some function deep 
inside the call chain under foo decides to use a GC buffer then 
it's a compile-time-error.