More radical ideas about gc and reference counting

[Timon Gehr via Digitalmars-d]

On 04/30/2014 10:21 PM, Andrei Alexandrescu 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).
>
> 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.
> ...

struct S{
     ~this(){ /* ... */ }
     /* ... */
}

class C{
     S s;
}

?

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

struct S{
     ~this(){ /* ... */ }
}

class C{
     S[] s;
     this(S[] s){ /* ... */ }
}

void main(){
     new C(buildSs());
     // memory leak
}

Also, cycles.