[Dlang-study] [lifetime] Few root decisions to take on RC classes

[Jonathan M Davis]

On Monday, November 02, 2015 20:43:50 Jakob Bornecrantz wrote:
> On Saturday, 31 October 2015 at 10:19:12 UTC, Jonathan M Davis
> wrote:
> > On Saturday, October 31, 2015 03:10:41 Jakob Bornecrantz wrote:
> >> Have you done any investigation how this effects exception
> >> handling and
> >> dynamic upcasts?
[snip]
> > The same goes with casting. Having a root object is irrelevant
> > to casting. As long as the class reference that you're casting
> > refers to an object whose type is either the target type or a
> > type derived from the target type, then the cast will succeed.
> > And if it doesn't, the result will be null. I don't see how the
> > existence of a root object would affect that.
> >
> > Remember that C++ doesn't have a root object, and exceptions
> > and casting work just fine there.
>
> Correct, but vtable will effect it. Casts on classes in D
> are dynamic by default unless they are downcasts.
>
> In C++ dynamic_cast wont work on classes that doesn't
> have a vtables, see example http://vp.dav1d.de/5ZOm?cpp I had
> to check for myself since it was a long time I programmed
> in C++ thanks to D. :)

Since we only have one cast operator in D, I'd fully expect it to be able to
sort this out. If an @rc class has no vtable, then there's no need to be
concerned with dynamic casts, and if it does, then casting to other classes
in its hierarchy should work as it does now - it's just that Object and any
class hierarchy built on it wouldn't be involved.

> I think just slapping @rc on Throwable will probably break code
> that is out there in the wild.

At minimum, @rc would have to be inherited by Throwable's descendants, or it
would definitely break code. Whether the difference in semantics would break
code or not, I don't know. I don't _think_ so, but I could be missing
something. Regardless, we really should find a way a to improve exceptions
so that they don't have to be GC-allocated (whether that's via ref-counting
or some other mechanism) so that exceptions can reasonably be used in @nogc
code, and given the fact that 99.999999% of the time, exceptions are
allocated, thrown, caught (maybe rethrown and recaught a few times), and
then no longer referenced anywhere in the code (rather than kept around
somewhere after the last catch block is exited), you'd think that it would
make sense for us to have a mechanism for the exception to be automatically
destroyed and its memory freed after that last catch block rather than
leaving it as garbage for the GC to clean up who-knows-when. And as long as
that mechanism doesn't destroy the exception if references to it exist after
the last catch block is exited, then I wouldn't think that doing something
like making Throwable @rc would break code.

So, it seems to me that we should at least explore the possibility of making
Throwable and its descendants @rc and see if that will solve those problems
for us. If it doesn't, then we need to find a different solution for that -
or maybe it's an indicator that @rc as currently described isn't quite where
we should be going.

- Jonathan M Davis