Yeah, I'm pretty sure it's the reason many C++ folks reject it. It's kind of ironic that having the "wrong" useful feature can hurt you, but that seems to be what's happening here. I feel like they might actually have a shot at solving it by literally dropping GC support, but it's hard to say at this point. I don't know if the standard library still has anything that needs a GC, but making sure that's not the case might be a good first step if they're ever interested in going in this direction.

> This is the logic I personally used in deciding not to use D.

Good call - I was unfortunate enough that I had to use it professionally for a few years. As comic book guy in the Simpsons would say "Worst language ever!".

> The actual difference is how frequent such libraries are in the respective ecosystem.

That’s a difference without a distinction: people will use the defaults unless they can’t.

So in C++ libraries will avoid GCs unless their work basically requires it, whereas in D they’ll require it unless the author is constrained to a nogc requirement.

I basically said as much https://news.ycombinator.com/item?id=34850130

Though, I'm not sure you could even have a precise GC for C++ even if you wanted to, given the way most C++ is written.

No, it's about pure D code. Some (many) people just don't want a GC in their program and that's why they use C++. If they switch to D, they'll have to put up with a GC if any of their dependencies needs one, and the probability of that being the case is... high.