On Wednesday, 7 October 2015 at 10:50:35 UTC, Namespace wrote:
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.
Well, except that then it's less obvious that an object is
ref-counted and less likely that the programmer using it will
realize that the object expects to have a deterministic lifetime.
So, it might actually make the situation worse and make it so
that programmers are more likely to get wrong. I don't think that
it's clear at all that the situation will be better with regards
to programmers getting it right if it's in the language. Maybe it
will be, but maybe it won't.
- Jonathan M Davis
