Alternative to Interfaces

[Jonathan M Davis]

On Friday, January 18, 2019 8:08:47 AM MST Kagamin via Digitalmars-d-learn 
wrote:
> On Friday, 18 January 2019 at 00:08:00 UTC, 1001Days wrote:
> > It works, but I have two questions regarding its efficacy: is
> > it viable in the long run, and is it now possible to use
> > delegates without the GC?
>
> GC is just a handy memory management approach, it even works for
> C and C++, (example: gcc), nothing in D needs GC if you manage
> memory in a different way. In fact there are D libraries that
> rely solely on manual memory management.

Yes, but some D features will use the GC, and you can't really stop that
aside from simply not using those features. The list of such features is
short, but delegates are on it. scope will get around the allocations in
some cases, but in general, if you use delegates, you're going to allocate
with the GC. There are alternatives to using delegates which will get you
similar behavior allocating (e.g. functors), but the allocations that happen
for delegates and lambdas is one of the biggest reasons that some folks
avoid std.algorithm and complain that it allocates. That's what happens when
you pass stuff that the compiler decides has to have closures allocated for
it. Completely avoiding the GC with D is possible, but it tends to require
that you be very careful and have a good understanding of where D needs to
use the GC to do what it does (though the fact that we now have @nogc, and
it screams at you if the code allocates does help you catch GC usage when
you didn't realize that it was there).

- Jonathan M Davis