named arguments, string interpolation, please stop.

[Richard (Rikki) Andrew Cattermole]

On 12/01/2024 2:36 PM, Siarhei Siamashka wrote:
>     So, anyone actually relying on @nogc preventing collections is
>     arguably asking for trouble even with the current GC - though it
>     seems like the kind of folks who like to use @nogc are often the
>     kind of folks who are likely to avoid the GC entirely, so if @nogc
>     is used everywhere in their code, then they won't end up with either
>     GC allocations or collections.
> 
> You are probably talking about the OS kernel developers. Something like 
> PowerNex, d-virtio and maybe a few other seemingly inactive/dead D projects.
> 
> But a common scenario for games is to load resources taking advantage of 
> the GC. And then try to avoid GC allocations in the main loop for 
> performance reasons. Do D language maintainers refuse to acknowledge the 
> existence of game developers? I think that there are a few of them in 
> this forum.

No, nobody is refusing such a clear use case. Especially when a few have 
been very vocal over the years and have had language features 
implemented for them.

What you are suggesting is that ``@nogc`` should for each function, call 
into the GC to disable/enable it automatically.

This is slow. You need to be responsible for doing this.
It should not be automated.

We can only guarantee in the compiler that this set of branches in the 
call stack will not trigger the GC. It is not possible to do other 
(potentially unknown) branches across all threads.

>     However, anyone using it selectively really can't rely on it to
>     avoid collections unless their program is single-threaded and will
>     always remain so.
> 
> What if the other threads are also |@nogc|?

"then they won't end up with either GC allocations or collections."