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.
Permalink
Reply
