Let's get the semantic around closure fixed.

deadalnix deadalnix at gmail.com
Thu May 20 12:25:03 UTC 2021


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

I don't expect this to be a huge deal in practice. There are many 
reasons for this I could go over, but the strongest argument is 
that literally any language out there does it and it doesn't seem 
to be a major issue.

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

You are making a categorical error here.

The delegate things is fundamentally different. The tradeof being 
discussed is between something that might be slow in some cases, 
versus something that is outright broken.

While we will all agree that possibly slow or confusing is bad, 
and that the argument stands for macro and alike, when the 
alternative is to produce something broken, it simply does not 
make sense.

Possibly slow can be useful nevertheless, depending on the 
specifics of the situation. Broken is never useful.



More information about the Digitalmars-d mailing list