Let's get the semantic around closure fixed.

Steven Schveighoffer schveiguy at gmail.com
Tue May 18 19:20:55 UTC 2021


On 5/18/21 3:04 PM, Ola Fosheim Grostad wrote:
> On Tuesday, 18 May 2021 at 18:51:40 UTC, Paul Backus wrote:
>> On Tuesday, 18 May 2021 at 17:53:20 UTC, Ola Fosheim Grostad wrote:
>>>
>>> Does a delegate do anything more than retaining a pointer to the 
>>> stack record?
>>> Anyway, it should not escape the scope it references. So escape 
>>> analysis is your friend.
>>
>> The compiler does escape analysis and pre-emptively allocates any 
>> variables that escape through closures on the GC heap.
>>
>> The bug here is that, for variables declared in loop bodies, the 
>> compiler *should* allocate a new copy on the heap for each loop 
>> iteration, but instead it only allocates one copy that's reused across 
>> all iterations.
> 
> Yes, absolutely. I dont use delegates much (well, I did in D1 but that 
> is a long time ago), but the difference between point 3 and point 7 in 
> the language reference is tricky to grasp. So if you bind a local 
> function to a delegate parameter you dont take a closure, but if you 
> assign to a delegate variable you get a closure?
> 
> "7. Delegates to non-static nested functions contain two pieces of data: 
> the pointer to the stack frame of the lexically enclosing function 
> (called the context pointer) and the address of the function."

There's also the issue that if you have a scoped variable that has a 
destructor, the value will be destroyed (and probably unusable) if you 
call the delegate from outside the scope.

-Steve


More information about the Digitalmars-d mailing list