https://issues.dlang.org/show_bug.cgi?id=15484
Vladimir Panteleev <dlang-bugzi...@thecybershadow.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Vladimir Panteleev <dlang-bugzi...@thecybershadow.net> --- (In reply to Daniel from comment #1) > Imagine an environment where you cannot even link with the GC, not because > of performance reasons but in order to reduce the size of your binary. Sounds like a good argument. I think it's better to be conservative, because it's easily possible to go the other way around in case of specific corner cases by creating a wrapper function that casts to @nogc. I'll close this (as the issue is over a year old), but feel free to reopen if you have a compelling argument to do so. (In reply to Infiltrator from comment #0) > // do something including allocations Not sure what you mean by this exactly; did you mean that the compiler would detect the GC.disable call and allow using "new" in-between GC.disable / GC.enable invocations, despite the @nogc attribute on the code? Because @nogc isn't supposed to mean "a GC collection cycle will not be triggered", but rather "no GC code is accessed at all" (which also refers to GC.enable/disable). --