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