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.
