D is GC by default (and currently required for larger parts of stdlib) but also allows disabling GC and doing manual memory management.

Just like plenty of GC enabled systems programming languages, this isn't a XOR.

D uses manual memory management with (malloc/free/realloc) to implement their GC

So i don't know what point you are trying to make

D is pragmatic and confirms my point

Like every systems programming language with GC support.

Modula-2+, Modula-3, Nim, Mesa/Cedar, .NET Native, Sing#, Oberon, Oberon-2, Oberon-07, Active Oberon, Nim, Swift (RC is a GC algorithm per CS definition), and even if debatable what its role might be, Go.

The point I am making is having a GC managed heap doesn't preclude features for manual memory management, only GC haters think otherwise.

You don't understand the point, GC is one way of managing memory, it is not the panacea

Some helpful reading, from people actually working on solving hard problems

https://twitter.com/FilmicWorlds/status/1562090212225716224

> only GC haters think otherwise.

only GC lovers think like that

that's not a good argument

Random links about a game studio, incidently one famous for using Lisp based scripting languages before being acquired by Sony.... yeah right.

You still don't get GC enabled system programming languages, and apparently I am not the one that is going to make it clear, so whatever.

You still don't get it, and that's ok

Indeed, why bother isn't it.