Let's get the semantic around closure fixed.

[Petar]

On Wednesday, 19 May 2021 at 20:27:59 UTC, Petar Kirov 
[ZombineDev] wrote:
> On Wednesday, 19 May 2021 at 20:14:18 UTC, Ola Fosheim Grostad 
> wrote:
>> On Wednesday, 19 May 2021 at 20:08:02 UTC, Petar Kirov 
>> [ZombineDev] wrote:
>>> 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.
>>
>> A trade-off is to issue a warning and provide a warning 
>> silencer.
>
> I see no point in having closure allocations causing compiler 
> warnings. That's what profilers are for. Every application has 
> different characteristics. Just because a newbie can write code 
> that ends up generating a ton of GC garbage doesn't mean that 
> closure allocations would even register on the performance 
> radar of many applications.

That said, there's the [`-vgc`][0] compiler switch, which prints 
during compilation all parts of the program that may cause a GC 
allocation. My point is that GC allocations shouldn't cause 
errors/warnings outside of `@nogc` code as we have plenty of 
tools to diagnose performance bugs.

[0]: https://dlang.org/dmd-linux.html#switch-vgc