Let's get the semantic around closure fixed.

[Walter Bright]

On 5/19/2021 10:26 AM, deadalnix wrote:
> On Wednesday, 19 May 2021 at 13:02:59 UTC, Steven Schveighoffer wrote:
>> 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.

Languages like D also need to be useful, not just correct. Having a hidden 
allocation per loop will be completely unexpected for such a simple looking loop 
for a lot of people. That includes pretty much all of *us*, too.

I doubt users will be happy when they eventually discover this the reason their 
D program runs like sludge on Pluto and consumes all the memory in their system. 
If they discover the reason at all, and don't just dismiss D as unusable.

The workaround, for the users, is to simply move that referenced variable from 
an inner scope to function scope.

It's best to just return a compile error for such cases rather than go to very 
expensive efforts to make every combination of features work.

It's similar to the decision to give an error for certain operations on vectors 
if the hardware won't support it, rather than emulate. Emulation will 
necessarily be very, very slow. Give users the opportunity to fix hidden and 
extreme slowdowns in code rather than hide them. A systems programming language 
ought to behave this way.