[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