DIP60: @nogc attribute

[Dicebot via Digitalmars-d]

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.

>> === Problem #2 ===
>>
>> The point where "I told ya" statement is extremely tempting :) 
>> bearophile has
>> already pointed this out - for some of language features like 
>> array literals you
>> can't be sure about possible usage of GC at compile-time as it 
>> depends on
>> optimizations in backend. And making @nogc conservative in 
>> that regard and
>> marking all literals as @nogc-prohibited will cripple the 
>> language beyond reason.
>>
>> I can see only one fix for that - defining clear set of array 
>> literal use cases
>> where optimizing GC away is guaranteed by spec and relying on 
>> it.
>
> I know that you bring up the array literal issue and gc a lot, 
> but this is simply not a major issue with @nogc. The @nogc will 
> tell you if it will allocate on the gc or not, on a case by 
> case basis, and you can use easy workarounds as necessary.

Beg my pardon, I have overstated this one indeed but temptation 
was just too high :) On actual topic - what "case by case" basis 
do you have in mind? There are no cases mentioned in spec when 
literals are guaranteed to not allocated AFAIK. Probably compiler 
developers know them but definitely not me.