Let's get the semantic around closure fixed.

[deadalnix]

On Wednesday, 19 May 2021 at 13:02:59 UTC, Steven Schveighoffer 
wrote:
> Thinking about how this would have to be implemented:
>
> 1. If you want to access a variable in a scope from both the 
> closure and the function itself, the variable has to be 
> allocated on the heap.

This is definitively what D guarantees.

> 2. We need one allocation PER loop. If we do this the way 
> normal closures are done (i.e. allocate before the scope is 
> entered), this would be insanely costly for a loop.

This is costly, but also the only way to ensure other invariants 
in the language are respected (immutability, no access after 
destruction, ...).

This is also consistent with what other languages do.

This is also consistent with the fact that D allow to iterate 
over loops using opDispatch, which already should exhibit this 
behavior, because it is a function under the hood.

> 3. It *could* allocate on demand. Basically, reserve stack 
> space for the captured variables, have a pointer to that stack 
> space. When a closure is used, copy that stack space to a heap 
> allocation, and switch the pointer to that heap block (so the 
> function itself also refers to the same data). This might be a 
> reasonable tradeoff. But it has some limitations -- like if you 
> ever take the address of one of these variables, that would 
> also have to generate the allocated closure.
>

I suspect this will open a can of worm of edge cases.