Discussion about deprecating @nogc and workarounds

[claptrap]

On Friday, 6 September 2024 at 09:37:48 UTC, solidstate1991 wrote:
> A lot of people are arguing (especially on Discord) that 
> `@nogc` should be discarded entirely in favor of betterC.

For real time audio the actual audio processing will either be in 
an OS callback, or a host callback in the case of a plugin. In 
both cases the "audio thread" will be an external thread that D 
runtime does not know about. And the only actual code that needs 
to be @nogc, (and no malloc etc), is in that callback. Just the 
actual audio processing code, well maybe some others in a plugin 
situation, stuff like events, automation will typically be 
delivered in the real time thread.

So you don't need the whole app to be @nogc, just the real time 
parts, and they will typically be less that 10% of the codebase.

So the "lets just remove the GC completely", or "just use a 
custom runtime", might be a good solution in some cases, but its 
a sledgehammer to crack a nut solution for others.

And tbh I don't see what it fixes? The problem, or what people 
are complaining about is that trying to make everything @nogc 
compatible puts a burden on people who don't care about it.

You don't need a custom runtime to fix that problem. You just 
need to stop trying to make all the things @nogc compatible. If 
it adds no baggage / burden to GC users then sure fine, but just 
accept D is a GC language, some of its core language features 
rely on GC, some of the stdlib will use GC.

I don't see massive amounts of posts from people complaining that 
this or that in the stdlib isn't usable in @nogc code?

Maybe its not a problem that needs fixing, or maybe @ogc people 
expect to have to do some extra work themselves.