DIP60: @nogc attribute

[Steven Schveighoffer via Digitalmars-d]

On Fri, 25 Apr 2014 09:20:08 -0400, Dicebot <public at dicebot.lv> wrote:

> On Friday, 25 April 2014 at 12:59:55 UTC, Steven Schveighoffer wrote:
>>
>> I don't know that it's desirable to have @nogc reject code even though  
>> an allocation does not occur. I agree the situation is not ideal, but  
>> @nogc is a practical optimization.
>>
>> I can think of other cases where the GC may be optimized out. To reject  
>> such code in @nogc would make it much less attractive.
>>
>
> It is unacceptable to have code that fails with one compiler and works  
> with the other despite the shared frontend version. Such "enhanced"  
> @nogc attributes must be placed into compiler-specific attribute space  
> and not as a core language feature.

Like I said, this may be the ideologically correct position, but please  
explain to the poor user that even though the compiler does not invoke the  
GC in his function, it still cannot be @nogc.

I think in this case, @nogc is not a good name.

But what really is the difference between a function that is marked as  
@nogc that compiles on compiler X but not compiler Y, and some custom  
attribute that compiles on X but not Y?

Consider that the fact that compiler X could have compiled a function that  
compiler Y is linking to, may actually be @nogc, because compiler X is  
better at avoiding GC calls. Wouldn't it make sense to be able to mark it  
@nogc and still use it from compiler Y?

-Steve