Let's get the semantic around closure fixed.

[Walter Bright]

On 5/19/2021 1:08 PM, Petar Kirov [ZombineDev] wrote:
> Make it work as expected. If it turns out to be a performance bottleneck for 
> some applications, they can always work around it, as obviously they had done 
> until now.

The point was that people will not realize they will have created a potentially 
very large performance bottleneck with an innocuous bit of code. This is a 
design pattern that should be avoided.

> Being conscious about performance trade-offs is important in language design, 
> but at the same time, just because someone can create a fork bomb with just 
> several lines of code doesn't mean that we should disallow every type of dynamic 
> memory allocation. For every misuse a of sound language feature, there are 
> plenty more valid usages.

Yeah, well, I tend to bear the brunt of the unhappiness when these things go 
wrong. A fair amount of D's design decisions grew from discussions with 
programming lead engineers having problems with their less experienced devs 
making poor tradeoffs.

I'm sure you've heard some of my rants against macros, version conditionals 
being simple identifiers instead of expressions, etc.

D has many ways of getting past guardrails, but those need to be conscious 
decisions. Having no guardrails is not good design.