On Tuesday, 16 June 2015 at 15:48:18 UTC, rsw0x wrote:
On Monday, 15 June 2015 at 16:20:56 UTC, Marc Schütz wrote:
I hope we won't get builtin RC, but that's off-topic.
I disagree, that's entirely on topic. I believe every modern
implementation of Ada relies solely on RC(while having GC
hooks.) Nobody really seems to have an issue with RC there. I
personally believe that immediate RC and GC solve completely
different issues of deterministic vs non-deterministic resource
management. Trying to shoehorn them into the same thing gets
you a broken, slow implementation(see: C++'s shared_ptr. It's
dog slow and _way_ overused IMO.)
Note that I'm all for supporting good RC, I'm just against adding
special support for it _in the language_. Instead, the remaining
obstacles for efficient and safe library-based RC should be
solved, which from my POV mostly means implementing some version
of the `scope` feature.
In any case, there has been talk about introducing finalizers
instead of destructors for GC managed objects.
rt_attachDisposeEvent() already exists and is used by
std.signal for weak references, but it's a hack, it needs to
be formalized.
These finalizers can then have much more restricted semantics
than destructors, e.g. they must be callable on any thread,
are generally un-@safe if they access members with
indirections, and so on.
I'm honestly curious of examples where finalizers are needed.
Well, as I already mentioned, weak references, e.g. for a
signal/slot mechanism, or for maintaining a cache that doesn't
keep its contents alive. Apart from that, I don't see much use in
them either. OTOH, weak references _are_ important, so there
needs to be some mechanisms for implementing them. I guess
finalizers are the easiest way to do it.
The one exception I can think of is managing non-GC objects, as
in C#. But that *still* seems like a bad idea because there's
zero guarantee the destructor will ever run - i.e, a GC
implementation that decides to just never call destructors is a
valid implementation.
Agreed.
http://dlang.org/class.html#destructors
"The garbage collector is not guaranteed to run the destructor
for all unreferenced objects. "
D has more than one issue here, from combining "finalizer" and
"destructor" into the same term to destructors being incredibly
bug-prone and almost useless as defined by the standard.
I hope this gets looked at.
Agreed, too.
