The easiest way to compete with Rust and cure D's GC reputation: switch to ARC.

[Richard (Rikki) Andrew Cattermole]

As a topic supporting ARC style memory management has long since been 
discussed. This isn't a new idea.

For ARC at the language level to exist, it requires that all memory in D 
would have to have a predictable state access. For example with a slice, 
not only do you need a pointer, length, but also the state object.

The way languages like Objective-C handle these issues, is to box raw types.

D has been designed foundationally to be based upon C. Our identifiers 
are defined against C23 (in process of upgrading from C99). The 
bitfields we just added? C's ABI.

C does not have ARC, its structs do not have methods, let alone state 
for this. Our struct layout matches C's.

This is of course before we even get to C++ stuff.

In otherwords, trying to transition the entire language over to ARC 
would break every D code base in existence, and on top of that remove 
aspects of D that people use with fervor.

GC algorithms like we have, are meant for memory that you do not care 
when cleanup occurs for it. You should not be using it for deterministic 
things.

For deterministic memory I recommend reference counting (including 
ownership transfer variation), or letting the call stack own the 
destruction ``scope(exit)``.

In hard realtime systems, any allocation during hot times means you've 
failed. It isn't deterministic intrinsically. You allocate upfront, and 
reuse memory in a way that can be predicted. But this requires you to 
understand your memory patterns which is a lot harder than it first 
seems. ARC doesn't change this. If you need ARC for these hot times, 
you've failed.

The ownership transfer wrappers that C++ has, are replicated in D.
https://dlang.org/phobos/std_typecons.html#Unique
Others examples of RC-like exist, including ones made by myself.

The above covers why we have not changed the entire language over to 
ARC. The D community values picking and choosing memory management 
strategies appropriate for the problem domain, not ideology.

So why don't we have RC in the language today, and have to work around 
it with copy constructors? Simply because we can't make them safe. 
Walter won't let it go in language without borrowing and we can't have 
that without a way to do the data flow analysis, which we can't have by 
default because it is slow and generates too many false positives.

Which is why I've been working on a fast data flow analysis engine that 
the community will hopefully accept it being on by default by preventing 
it reporting false positives. It won't of course make everyone happy so 
we'll also need a slow DFA that includes all the fun and more advanced 
analysis with the false positives.

Ownership transfer is a derivative of reference counting, specifically I 
would like us to have isolated from Midori. But again that needs a DFA.