[Issue 15484] core.memory.GC.disable() is not @nogc
via Digitalmars-d-bugs
digitalmars-d-bugs at puremagic.com
Fri Jul 21 00:52:47 PDT 2017
https://issues.dlang.org/show_bug.cgi?id=15484
Vladimir Panteleev <dlang-bugzilla at thecybershadow.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #2 from Vladimir Panteleev <dlang-bugzilla at 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).
--
More information about the Digitalmars-d-bugs
mailing list