https://issues.dlang.org/show_bug.cgi?id=15484

Daniel <wyrlon@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wyrlon@gmx.net

--- Comment #1 from Daniel <wyrlon@gmx.net> ---
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.

For this reason, no single function/symbol which is part of the GC should be allowed in @nogc code, regardless if it allocates or not.

--

https://issues.dlang.org/show_bug.cgi?id=15484

Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #2 from Vladimir Panteleev <dlang-bugzilla@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).

--

https://issues.dlang.org/show_bug.cgi?id=15484

Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario@gmx.de

--- Comment #3 from Rainer Schuetze <r.sagitario@gmx.de> ---
>  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).

My impression is that everybody has a different notion of what @nogc means. Contrary to your assumption, GC.addRoot and GC.addRange have been marked @nogc. The spec only says "@nogc applies to functions, and means that that function does not allocate memory on the GC heap" which still disallows foo() to be @nogc.

--

https://issues.dlang.org/show_bug.cgi?id=15484

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |schveiguy@yahoo.com
         Resolution|WONTFIX                     |---
           Severity|normal                      |enhancement

--- Comment #4 from Steven Schveighoffer <schveiguy@yahoo.com> ---
@nogc means no allocations, no more no less. See Walter here: https://forum.dlang.org/post/ogal82$2ubk$1@digitalmars.com

I can see a use case for this, but not with the OP's code, since it has allocations (and obviously those aren't @nogc).

But if you were in, let's say a critical part of a rendering loop, and did not want to drop frames, you may disable the gc to prevent *other threads* from collecting during this critical period, and then turn it back on.

So I think the enhancement request is legitimate.

--

https://issues.dlang.org/show_bug.cgi?id=15484

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--