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?
