The D standard library is built on GC, is that a negative or positive?

[Dukc]

On Tuesday, 13 December 2022 at 07:11:34 UTC, thebluepandabear 
wrote:
> Hello,
>
> I was speaking to one of my friends on D language and he spoke 
> about how he doesn't like D language due to the fact that its 
> standard library is built on top of GC (garbage collection).
>
> He said that if he doesn't want to implement GC he misses out 
> on the standard library, which for him is a big disadvantage.
>
> Does this claim have merit? I am not far enough into learning 
> D, so I haven't touched GC stuff yet, but I am curious what the 
> D community has to say about this issue.

He said he must "implement" the GC? Does this mean he's going to 
program for some rare target platform where D does not offer GC 
of the box? If so this somewhat but not quite correct. Parts of D 
standard library do work with `-betterC` or otherwise stripped 
down DRuntime to some extent, but it's quite unstable and often 
requires workarounds.

On the other hand, if the intention is to simply avoid using the 
GC, this claim is mostly wrong. Big part of the standard library, 
probably most of it, works. For example:

```D
@safe @nogc vectorLength(double[] vec)
{   import std.array, std.algorithm, std.math;
     return vec.map!"a*a".sum.sqrt;
}
```

There are still some tasks, like Unicode normalization, that 
don't work, but almost all of the core functions in 
`std.algorithm` and `std.range` are GC-free, plus many of the 
other tasks.