Voldemort declarations inside structs with ctor initialization

[Meta via Digitalmars-d]

On Wednesday, 28 May 2014 at 06:20:29 UTC, Idan Arye wrote:
> From what I know(don't know how it is implemented in D. I know 
> it doesn't work that way in languages that emulate closures 
> like C++ and Java) delegates don't "allocate a closure" - 
> rather, they use a the callstack frame that was already 
> allocated by the function as a closure. While it's true that 
> they have to save a reference to that frame, there is no 
> separately GCed memory for saving that reference - it's stored 
> in the fat pointer together with the function pointer.

What I meant to say by "allocate a closure" is that variables in 
the stack frame that the delegate has a pointer to are moved to 
the heap when they go out of scope. I believe this implies GC 
allocation, but I'm not 100% sure. If that *were* the case, then 
you can see that marking the delegate as @nogc would mean that 
code such as your example would fail to compile.


> The lambdas in my example don't allocate any memory when you 
> *run* them.

I'm not completely sure whether they will or they won't... But 
I'm pretty sure that this modified example will:

auto foo()
{
     int a;

     return () => is(typeof(a) : char);
}

void main()
{
     writeln(foo()());
}


> At any rate, a delegate without a closure is either a 
> `function`(which can be body-hashed without any problem) or a 
> method(which doesn't need body-hashing), so having the @nogc 
> restriction would be pointless even if @nogc prevented closures.

How is this restriction pointless if it means that delegates that 
couldn't be hashed before due to their context can now be hashed?