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