On Tuesday, 27 October 2015 at 20:19:42 UTC, PuglyWUgly wrote:
Why care about this?
Even Rust doesn't try to solve this problem...because it isn't
really a problem in practice.
In c++/rust code you use value/unique types 99.9% of the time,
and reference counting is only for shared/aliased objects.
Reference counting == rare and unimportant
Really? I've seen tons of C++ code that's written using smart
pointers with objects living on the heap which then get passed
around all over the place.
Sure, a lot of stuff in D should be structs on the stack, but
there are plenty of cases where you need stuff on the heap, in
which case, you either have to let the GC take care of it (which
means no deterministic destruction), have something specific own
it and destroy it when it's no longer needed, or reference count
it so that it gets destroyed immediately after it's no longer
needed. For cases where you don't care about deterministic
destruction, using the GC is fine, but for those cases where
deterministic destruction is required (e.g. because the object
currently has ownership of an OS resource), the GC doesn't cut
it, and ref-counting is very much what's needed.
If/when we introduce ref-counting into the language, I fully
expect that there will be a lot of D programs written which
specifically use it in order to avoid the GC. And while in many
cases, that's going to be an unnecessary, in some cases, it'll be
a lifesaver.
As it stands, we can add ref-counting via libraries just fine,
but it requires giving up on @safe, which we could probably live
with, but it would make @safe a lot less valuable in the long
run. So, a solution that enables @safe ref-counting in D would
certainly be desirable, and we definitely need a language
improvement of some kind if we want to be able to ref-count
something like exceptions (be it by building ref-counting into
the language like Andrei is proposing or by adding other features
which enable us to build it in the library like deadalnix is
proposing).
- Jonathan M Davis
