Let's get the semantic around closure fixed.

[Max Haughton]

On Friday, 28 May 2021 at 14:29:50 UTC, Paul Backus wrote:
> On Friday, 28 May 2021 at 13:47:32 UTC, deadalnix wrote:
>> On Friday, 28 May 2021 at 02:47:41 UTC, Adam D. Ruppe wrote:
>>> On Friday, 28 May 2021 at 02:41:27 UTC, Q. Schroll wrote:
>>>> I was a little surprised that it needs the GC in the first 
>>>> place. It's a template parameter after all.
>>>
>>> It isn't the lambda that allocates per se, it is the 
>>> `MapResult` struct that cannot necessarily be scope since it 
>>> doesn't know if the range will be stored or returned or 
>>> whatever.
>>>
>>> Though perhaps if the returned map result inherited the 
>>> lifetime of the captured variables it could work, just that 
>>> gets complicated.
>>
>> I suspect the compiler should be able to see through it after 
>> a few rounds of inlining.
>>
>> If there are so many layers that it doesn't, I suspect one 
>> allocation isn't going to be your bottleneck.
>
> `ldc -O` is able to elide the allocation: 
> <https://d.godbolt.org/z/9aoMo9hbe>
>
> However, the code still does not qualify as `@nogc`, because 
> `@nogc` analysis is done prior to optimization.

Some more context (i.e. how LDC goes about doing this)

https://d.godbolt.org/z/jsPdoTxY1

https://github.com/ldc-developers/ldc/blob/master/gen/passes/GarbageCollect2Stack.cpp

GCC does not do this optimization (yet?), but it does for malloc 
and new in C++.