Frameworks and libraries

[Jonathan M Davis]

On Friday, September 15, 2023 2:38:12 PM MDT Atila Neves via Digitalmars-d 
wrote:
> std.string, I get, but algorithm and range are poster children
> for `@nogc`. I'm not going to claim that *nothing* in those
> packages allocates on the GC heap, but I'd be very surprised if
> there were many functions that did.

I recall complaints in the past about not being able to use @nogc with
std.algorithm and friends due to issues with lamdbas allocating closures. I
don't know that that's actually an issue at this point (and it really
shouldn't be in general), but it can also be worked around with other forms
of callables if need be. It's just more annoying than using a lambda.

But yeah, there should be _very_ little in terms of explicit allocations
occuring in std.algorithm (possibly even none). It's templated and designed
to operate on generic ranges, and very little of it does anything with
exceptions, so almost none of it should be allocating anything - though of
course, if your ranges themselves can't be @nogc for some reason, then
obviously, std.algorithm can't be either. So, I suspect that strings, for
instance, can't be @nogc with std.algorithm (at least without byCodeUnit)
due to the decoding possibly throwing. A lot of other stuff should be able
to work with std.algorithm and be @nogc with no problem though.

- Jonathan M Davis