D is our last hope

[GrimMaple]

On Thursday, 7 December 2023 at 10:08:14 UTC, Siarhei Siamashka 
wrote:
> Is this actually true? My understanding is that `@nogc` code 
> fragments can be called from the GC code just fine. Though some 
> problems may arise with callback functions or 
> delegates/closures here and there.

I would've lied if I said you can't use `@nogc` code in GC code. 
But in a reasonably sized framework (eg UI framework) `@nogc` 
will start bringing in too much issues eventually. Delegates is 
just one of the things where `@nogc` issues are apparent. If you 
want to have a `@nogc` control in a UI framework and have 
callbacks/events in it, you are going to force the user of that 
control to use `@nogc` code.

The less apparent issue with `@nogc` are interfaces\subclasses. 
If you have a `@nogc` in your interface, you're kind of forcing 
`@nogc` onto all of the users of that interface:

```d
interface A
{
     void a() @nogc;
}

class B : A
{
     void a() { writeln("b"); } // Oops -- a() is @nogc
}
```

> Or do you mean that manual dynamic memory 
> allocation/deallocation in the `@nogc` library can make things 
> much more complicated?

This is probably the least of my concerns, because

> But if a `@nogc` library never exposes manually allocated 
> memory slices to its API users, then everything is fine. In 
> fact, various C libraries (such as glibc, zlib, sqlite) are all 
> effectively `@nogc` and they can be used from D code.

that only works if you don't have any reasonably complex 
inheritance structure in your code. If you have subclasses and 
stuff, this manually allocated stuff becomes almost impossible to 
reasonabley control from either side.