D is our last hope

[Siarhei Siamashka]

On Tuesday, 5 December 2023 at 21:26:05 UTC, GrimMaple wrote:
> If you design a `@nogc` library, then GC people are left out.

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. An example of `@nogc` induced friction:

```D
import std;
void main() {
   auto a = new BigInt[](100);
   a[] = BigInt(1);  // works fine
   a[] += BigInt(1); // Error: `@nogc` function 
`core.internal.array.operations.arrayOp!
                     // (BigInt[], BigInt, "+=").arrayOp` cannot 
call non- at nogc function
                     // `std.bigint.BigInt.opOpAssign!("+", 
BigInt).opOpAssign`
}
```

Or do you mean that manual dynamic memory allocation/deallocation 
in the `@nogc` library can make things much more complicated? 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.