Let's get the semantic around closure fixed.

[Petar]

On Thursday, 20 May 2021 at 09:42:20 UTC, Ola Fosheim Grostad 
wrote:
> On Wednesday, 19 May 2021 at 20:56:10 UTC, Paul Backus wrote:
>> On Wednesday, 19 May 2021 at 19:01:59 UTC, Walter Bright wrote:
>> If closuras causing "hidden" allocations is problematic, from 
>> a language-design perspective, then it's problematic whether 
>> it occurs inside a loop or not. Either we should (a) deprecate 
>> and remove GC-allocated closures entirely, or (b) make them 
>> work correctly in all cases.
>
> Or better, acknowledge that there is a difference between low 
> level and high level projects (or libraries), and let low level 
> programmers get warnings that they can silence while allowing 
> high level programmers to have an easy life.

I strongly agree with both you and Paul. One D's biggest 
strengths in my experience is that it's not good for just one 
area, but many, each with it's own challenges. If I were to write 
a kernel module, I wouldn't even consider using the GC or linking 
druntime, while for scripting (which D is surprisingly good at) I 
would never bother with manual memory management or smart 
pointers. There are plenty of languages that force a single 
"right" solution; we don't need to copy the limitations from them.

If people don't want to use any parts of druntime that may incur 
run-time or non-optional code-size cost (e.g. `Object.factory`) 
they can always use `-betterC` in their build scripts. If they 
just don't want the GC, then there's no `@nogc` function 
attribute and the `-vgc` compiler switch. We should also make is 
so you can put function attributes before `module` declarations 
to enforce them transitively for the whole module, so that you 
can put `@nogc module foo;` once and for all and not have to 
bother putting it on every function. There's probably some 
percentage of anti-GC people who tried D and were put off by the 
"GC tax" of having to annotate every single function with `@nogc` 
(there are more efficient ways to annotate multiple symbols with 
a give set of attributes, but they probably haven't taken the 
time to learn them).

For past past 5-7 years, I can't think of a single new language 
feature that required the GC. We have been going the @nogc / 
DasBetterC road long enough (*). I think we shouldn't "skip leg 
day" any more and we should improve a bit the high-level side of 
D. Failing that, we should remove heap-allocated closures from 
the language as it brings more harm to keep them working wrong 
than not having them at all.

(*) Obviously, I don't mean we should stop improving in that 
direction (quite the opposite), but that we can afford to improve 
in other directions as well, without diminishing our current 
strengths.