Bug 1760 – Closures - Variable unnecessarily allocated on heap

Using this sample code: int delegate() three(){ int a = 35; int b = 60; int c = 75; int geta(){ return a; } int getb(){ return b; } writeln(&a); writeln(&b); writeln(&c); return &geta; } void main(){ three(); } Prints: 892FF4 892FF8 12FF28 This means that 'int b' is allocated on the heap, even though the function 'int getb()' is never referenced.

Not a bug, but a limitation.

[email protected] wrote: > is means that 'int b' is allocated on the heap, even though the function > 'int getb()' is never referenced. As Matti says, sort of a limitation, but not really one it is possible to solve because the compiler can never know if an object referencing it is linked in later on.

Lars Ivar Igesund wrote: > [email protected] wrote: > >> is means that 'int b' is allocated on the heap, even though the function >> 'int getb()' is never referenced. > > As Matti says, sort of a limitation, but not really one it is possible to > solve because the compiler can never know if an object referencing it is > linked in later on. I disagree. In the example, no delegate pointing to three.getb() is ever created inside three(), and no other code can get to the symbol since it isn't in scope anywhere else. So the compiler could tell getb() doesn't even need to be emitted and 'b' can be stack-allocated, if only it would try to determine that fact.

Frits van Bommel wrote: > Lars Ivar Igesund wrote: >> [email protected] wrote: >> >>> is means that 'int b' is allocated on the heap, even though the function >>> 'int getb()' is never referenced. >> >> As Matti says, sort of a limitation, but not really one it is possible to >> solve because the compiler can never know if an object referencing it is >> linked in later on. > > I disagree. In the example, no delegate pointing to three.getb() is ever > created inside three(), and no other code can get to the symbol since it > isn't in scope anywhere else. So the compiler could tell getb() doesn't > even need to be emitted and 'b' can be stack-allocated, if only it would > try to determine that fact. Good point, didn't look to the top to see that it's all inside a delegate.

Lars Ivar Igesund wrote: > Frits van Bommel wrote: > >> Lars Ivar Igesund wrote: >>> [email protected] wrote: >>> >>>> is means that 'int b' is allocated on the heap, even though the function >>>> 'int getb()' is never referenced. >>> As Matti says, sort of a limitation, but not really one it is possible to >>> solve because the compiler can never know if an object referencing it is >>> linked in later on. >> I disagree. In the example, no delegate pointing to three.getb() is ever >> created inside three(), and no other code can get to the symbol since it >> isn't in scope anywhere else. So the compiler could tell getb() doesn't >> even need to be emitted and 'b' can be stack-allocated, if only it would >> try to determine that fact. > > Good point, didn't look to the top to see that it's all inside a delegate. Small correction: It's not all in a delegate. It's all in a function (that happens to return a delegate). Not that it matters here...

@RazvanN7 created dlang/dmd pull request #10442 "Fix Issue 1760 - Closures - Variable unnecessarily allocated on heap" fixing this issue: - Fix Issue 1760 - Closures - Variable unnecessarily allocated on heap https://github.com/dlang/dmd/pull/10442

Closing as WONTFIX on the basis of: https://github.com/dlang/dmd/pull/10442