Let's get the semantic around closure fixed.

[Petar]

On Thursday, 20 May 2021 at 01:21:34 UTC, Walter Bright wrote:
> 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.

If they didn't realize it's a performance bottleneck, like it 
wasn't that important enough to profile ;) People who value 
performance often are willing to go to great lengths to achieve 
it. I'm saying that we should make they path harder, but that 
it's not a hard problem to diagnose, so that we would force a 
type system hole on everyone (see Paul's post for an example: 
https://forum.dlang.org/post/bscrrwjvxqaydbohdjuw@forum.dlang.org), just because someone may misuse it and create a perf bottleneck (I'm doubtful that this would be anywhere high on the list of possible problem in most programs).

>> 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.

I strongly agree with the sentiment that language/library design 
should guide users into making the right choice. The "pit of 
success" and all that. In this instance however, we don't have 
"limitation for the greater good", but a series of implementation 
(or design) issues that break D's type system. Let's focus on 
cleaning the foundation of the language, as the more we wait, the 
more painful the transition may be in the future if we delay.