On Wed, 30 Apr 2014 16:21:33 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Walter and I have had a long chat in which we figured our current
offering of abstractions could be improved. Here are some thoughts.
There's a lot of work ahead of us on that and I wanted to make sure
we're getting full community buy-in and backup.
First off, we're considering eliminating destructor calls from within
the GC entirely. It makes for a faster and better GC, but the real
reason here is that destructors are philosophically bankrupt in a GC
environment. I think there's no need to argue that in this community.
The GC never guarantees calling destructors even today, so this decision
would be just a point in the definition space (albeit an extreme one).
destructors are for cleaning up non-GC resources. File handles, malloc'd
memory, etc. I don't see why these need to be eliminated.
What about changing destructors so that they DON'T implicitly call member
struct dtors? I'd prefer that, since struct dtors executed on the heap I
agree are an issue. One can always call the dtor in the class dtor if
necessary. Right now, you have no choice.
That means classes that need cleanup (either directly or by having
fields that are structs with destructors) would need to garner that by
other means, such as reference counting or manual. We're considering
deprecating ~this() for classes in the future.
So essentially, any class with a dtor needs reference counting? How does
one clean up a cycle of them?
Slices T[] of structs with destructors shall be silently lowered into
RCSlice!T, defined inside object.d. That type would occupy THREE words,
one of which being a pointer to a reference count. That type would
redefine all slice primitives to update the reference count accordingly.
This is a possibility, but I think you would need to prove performance is
not severely affected.
I foresee any number of theoretical and practical issues with this
approach. Let's discuss some of them here.
I'd rather see a RC array type, which specifically supports reference
counting for opt-in support.
But we are getting WAY ahead of ourselves. A workable RC solution has to
be proven first. I'd feel much more comfortable making such a change with
a working, tested solution to look at.
-Steve
