DIP60: @nogc attribute

[Walter Bright via Digitalmars-d]

On 4/17/2014 8:02 AM, Dicebot wrote:
> === 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:

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.


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