named arguments, string interpolation, please stop.

[Siarhei Siamashka]

On Thursday, 11 January 2024 at 23:09:46 UTC, Jonathan M Davis 
wrote:
> @nogc doesn't even prevent collections running while a function 
> is called. It just prevents that specific function from 
> triggering the collection (thanks to no allocations triggering 
> it). Another thread could trigger a collection while that 
> function is running. So, yes, in a single-threaded program, 
> it's equivalent to calling GC.disable, but in the general case, 
> it isn't.

Or another thread could just call GC.enable/GC.collect and we are 
in a trouble either way, no matter what we do. Wouldn't it make 
sense to implement this other thread in a way that it properly 
cooperates with the main thread?

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

> 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`?