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

On Thursday, 11 January 2024 at 20:03:36 UTC, Paolo Invernizzi wrote:
>
> I've no ideas how you can have a list or external created pthreads without horrible hack like hooking pthread_create.
>


Ocaml is exactly like D with that: https://v2.ocaml.org/manual/intfc.html#ss:c-thread-register

On 1/12/24 03:27, Siarhei Siamashka wrote:
> But the OpenD fork doesn't care about the `@nogc` use case.

I don't think it's exactly like that, they mostly just dislike the pattern of rejecting new features for introducing implicit GC allocations. Anyway, personally I think something like @localnogc can be part of embracing the GC.

On Friday, 12 January 2024 at 01:21:32 UTC, H. S. Teoh wrote:
>
> The only way a library author can deal with this mess is (1) write in the most restricted language subset, i.e., betterC + @nogc, so that it's usable by everybody. But the GC crowd will be unlikely to use it, because it will lack the conveniences they're accustomed to, the API will have manual memory management paraphrenalia that doesn't fit well with the rest of user code. Plus this is also a much higher bar for the library author, so you're further limiting the already small number of people who are writing D libraries.  Or (2) be opinionated and write a GC-using library, in which case the betterC / @nogc people won't use it. Either alternative leads to ecosystem fragmentation. Or write a @nogc library but the betterC people won't use it.  Etc..
>

Interesting post thanks. Describes the situation very well.
I think more escape hatches (@localnogc?) may help with the delegate situation you related.