Language-supported ref-counting wouldn't fix that. As long as
you're allowed to put a ref-counted object inside of a
GC-managed object, it's possible that the GC will ultimately
managed the lifetime of your ref-counted object - or even that
it will never be destroyed, because it simply isn't collected
prior to the program shutting down. And it's not like we're
going to make it illegal to put a ref-counted object inside of
a GC-managed object. That would be needlessly restrictive.
Ultimately, programmers simply have to be smart about what they
do with objects on the GC heap if deterministic destruction is
required.
Having ref-counting built into the language will allow us to
make it more efficient and provide some safety guarantees that
can't necessarily be provided in a struct, but it doesn't make
it so that no one can misuse ref-counted objects.
Ultimately, the largest benefit to having ref-counting built
into the language will probably be that we can the have
exceptions be reference counted - and maybe even make it so
that they're malloced normally so that they can be used in
@nogc code. Most of the benefits of ref-counting can already be
done with structs.
- Jonathan M Davis
Sure, there are, of course, still ways to avoid the guarantees.
But it's more likely that others write A a = new A("Hello");
instead Unique!A a = unique!A("Hello"); so we increase the
probability that others get it right.
