DIP60: @nogc attribute

[Steven Schveighoffer via Digitalmars-d]

On Fri, 25 Apr 2014 11:12:54 -0400, Dicebot <public at dicebot.lv> wrote:

> On Friday, 25 April 2014 at 14:01:07 UTC, Steven Schveighoffer wrote:
>>> 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.
>
> Which is the very reason why I was so insisting of defining exact set of  
> cases when optimisation is to be guaranteed in spec (before releasing  
> @nogc). Unfortunately, with no success.

Well, @nogc is not released yet. Please tell me we don't have to avoid  
breaking code based on git HEAD...

>
>> 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?
>
> There are no user-defined attributes that can possibly fail on only some  
> compiler. And compiler-specific attributes are part of that compiler  
> documentation and never part of language spec. This is the difference.

But such a situation would not violate a spec that says "@nogc means there  
are no hidden GC calls." And the end result is identical -- I must compile  
function foo on compiler X only.

I agree there are likely no precedents for this.

Another option would be to put such a compiler-specific attribute around  
the code in question rather than a different attribute than @nogc on the  
function itself. I think there's really no avoiding that this will happen  
some way or another.

-Steve