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.
