What you are suggesting is that we use a GC in unsafe
code. This is odd, because we have unsafe
in GC languages to do the opposite: to be able to ignore the GC.
The niche case you're suggesting is that where you need to use unsafe
to describe something that cannot be described with lifetimes due to restraints or inconclusive determinations on behalf of the compiler.
If your structure can't be described with lifetimes there is a chance your problem is not meant to be solved that way in Rust. And even then, if I really wanted to build such a structure in safe Rust, I can. With structures which mimic a GC. Those are Rc
and Arc
from std
or similar structures from other crates.
If a GC were heavily integrated into Rust (Even in an unsafe
context), then chances are it wouldn't interact nicely, simply because a static, compile time construct like lifetimes is created for the sole reason of doing what a GC does (memory safety) without a GC.
It also seems you're under the impression that unsafe
Rust requires you to manually de-allocate things and go back to the archaic malloc
/free
everywhere ways. That is not true. Everything I use in safe code I can use perfectly fine in unsafe
code. unsafe
code just enables constructs the compiler cannot prove to be safe to use in a given context. For example: raw pointers are untracked and cannot be proven by the compiler to be safe to dereference. Or an intrinsic function that is simply too contrived and niche to the language to have the compiler try and decide when it's safe to use.