More radical ideas about gc and reference counting

[Andrei Alexandrescu via Digitalmars-d]

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).

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.

Also, we're considering a revamp of built-in slices, as follows. Slices 
of types without destructors stay as they are.

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.

RCSlice!T will not convert implicitly to void[]. Explicit cast(void[]) 
will be allowed, and will ignore the reference count (so if a void[] 
extracted from a T[] via a cast outlives all slices, dangling pointers 
will ensue).

I foresee any number of theoretical and practical issues with this 
approach. Let's discuss some of them here.


Thanks,

Andrei