On Friday, 25 May 2012 at 07:13:11 UTC, Jacob Carlborg wrote:
On 2012-05-24 21:46, foobar wrote:
Looks to me like an issue with separation of concerns. I think
that
dtors need to only provide deterministic management of
resources and not
affect GC algorithms:
1. classes should *not* have dtors at all.
2. struct values should *not* be gc managed [*].
Composition of classes and structs should be handled as
follows:
1. If a class contains a pointer to a struct it doesn't scan
it in a GC
cycle. The runtime can provide a hook so that structs could
register a
callback for RC purposes.
2. When a class contains a strcut value, they share the same
lifetime
thus the GC will call the struct's dtor when the object is
collected.
How is that any different than having destructors for classes.
It makes the call order deterministic like in C++.
e.g.
class Foo {}
struct A {
resource r;
~this() { release(r); }
}
struct B {
A* a;
Foo foo;
~this() { delete a; } // [1]
}
Lets look at point [1]:
The "foo" instance is "managed" by the GC since the only resource
it holds is memory. The "a" member wraps some "non-managed"
resource (e.g. file descriptor) and in this model is still valid,
thus allows me to deterministically dispose of it as in c++.
This can be simply checked at compile-time - you can only
reference non class instance members in the destructor, so adding
a "delete foo;" statement at point [1] simply won't compile.
