Let's get the semantic around closure fixed.

[Max Haughton]

On Friday, 21 May 2021 at 00:31:52 UTC, TheGag96 wrote:
> On Thursday, 20 May 2021 at 12:31:00 UTC, Steven Schveighoffer 
> wrote:
>> On 5/19/21 9:02 AM, Steven Schveighoffer wrote:
>>
>>> Of course, with Walter's chosen fix, only allowing capture of 
>>> non-scoped variables, all of this is moot. I kind of feel 
>>> like that's a much simpler (even if less convenient) solution.
>>
>> After reading a lot of this discussion, I have changed my 
>> mind. We should implement the "correct" thing even if it 
>> performs poorly. While Walter's solution gets the compiler out 
>> of responsibility, it doesn't square with the fact that 
>> closures are already hidden allocations, so consistency 
>> dictates we deal with inner allocations the same way.
>>
>> We need one heap block per scope that has captured variables. 
>> Expensive, but I don't see a way around it. Hopefully 
>> optimizers and scope delegates can alleviate performance 
>> issues.
>>
>> -Steve
>
> Yeah... Honestly, that getting-around-immutable thing seems 
> like the nail in the coffin for the current behavior. Hopefully 
> making it work "correctly" won't be too painful...
>
> The delegate-related thing I really want improved is being able 
> to capture local variables in places like:
>
> ```d
> int i = 3;
> someRange.map!(x => x.thing == i).each!writeln;
> ```
>
> ...without needing the GC, since we "know" that `i` doesn't 
> escape. Dunno if that's a pipe dream, though.

This has to be an aim. It's simply stupid that using map in the 
way it's intended to be used results in a GC allocation (there 
are workarounds, but this is missing the point entirely). I know 
it won't be easy, but quite frankly if it's not possible that's a 
knock on us and our infrastructure - if we can't do big and 
important things properly we need to change that too.