DIP60: @nogc attribute

[Dicebot via Digitalmars-d]

On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
> http://wiki.dlang.org/DIP60
>
> Start on implementation:
>
> https://github.com/D-Programming-Language/dmd/pull/3455

OK, a bit late to the thread, seeing how it has already went to 
ARC off-topic domain :( An attempt to get back to the original 
point.

I was asking for @nogc earlier and I find proposed implementation 
too naive to be practically useful, to the point where I will 
likely be forced to ignore it in general.

=== Problem #1 ===

First problem is that, by an analogy with `pure`, there is no 
such thing as "weakly @nogc@". A common pattern for performance 
intensive code is to use output buffers of some sort:

void foo(OutputRange buffer)
{
     buffer.put(42);
}

`foo` can't be @nogc here if OutputRange uses GC as backing 
allocator. However I'd really like to use it to verify that no 
hidden allocations happen other than those explicitly coming from 
user-supplied arguments. In fact, if such "weakly @nogc" thing 
would have been available, it could be used to clean up Phobos 
reliably.

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:

=== 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.