On Wednesday, 7 October 2015 at 11:21:04 UTC, Namespace wrote:
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
Well then, there is another solution: enable inheritance for
structs as well. Then we have polymorphie and deterministic
lifetimes. Of course we cannot expect too much magic. But an
example:
How does that solve anything? The problem is that some types need
a deterministic lifetime, and no object whose lifetime is managed
by the GC gets a deterministic lifetime. So, even if an object
supports deterministic destruction, that stops working as soon as
its put inside of something whose lifetime is managed by the GC.
Whether the object with deterministic destruction has inheritance
or not doesn't really matter, and whether it naturally has
deterministic destruction or whether it has it because it's being
used in smart pointer doesn't really matter. It's the fact that
it was put in an object whose lifetime is managed by the GC that
screws with things.
Even if D classes were identical to C++ classes, and we had no
structs, the fact that we have a GC managing the lifetime of
anything causes problems with any type that needs deterministic
destruction.
What's needed is to have a smart pointer of some kind to manage
the lifetime of objects on the heap that need deterministic
destruction and then to have the programmer make sure that they
do put any of such objects inside of an object whose lifetime is
managed by the GC if they want the deterministic destruction to
work. You can't get away from requiring the programmer to be
smart about things here unless you simply have no GC (which then
requires them to smart about other things), or any type with
deterministic destruction simply isn't allowed to be on the GC
heap, which is unnecessarily limiting, particularly since in many
cases, it's perfectly okay to let objects that might normally be
destroy deterministically to be destroyed at the GC's leisure.
std.typecons.RefCounted aside, it's quite possible as-is to
implement smart pointers in D with structs, thus providing
deterministic destruction for reference types. I don't know why
RefCounted wasn't implemented to work with classes, and I don't
know why Walter and Andrei think that something like DIP 74 is
necessary to support ref-counting. I might have heard, but if so,
I forgot. It probably comes down to a loophole somewhere in how
structs are put together that makes it throw off the ref-count
(maybe something to do with init values), but that's speculation
on my part. Regardless, if we have a proper ref-counting
mechanism for classes (built-in or not doesn't necessarily matter
- it just needs to work), then the folks that need deterministic
destruction with polymorphism get it. But they're always going to
have be careful about having such objects on the GC heap due to
the nature of garbage collection.
- Jonathan M Davis
