On Wed, 30 Apr 2014 13:21:33 -0700 Andrei Alexandrescu via Digitalmars-d <[email protected]> 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). I really don't like the fact that struct destructors are not called by the GC, and if anything, I'd be inclined to argue for finding a way to guarantee that they get run rather than guaranteeing that they never get run. It's just far too easy to have a struct expect that its destructor will be run and then have issues when it's not run. But it would be better to define struct destructors as never getting run rather than having it be undefined as it is now. > We're considering deprecating ~this() for classes in the future. While it's not good to rely on finalizers, they're good to have as backup if the appropriate cleanup function doesn't get called like it's supposed to. They're not as critical as they'd be in Java, since we have structs, but I'd be disinclined to remove finalizers from D without a really good reason. > 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. I'm really going to have to think about this one. It's such a radical change that I really don't know what to think about it. It will be interesting to see what others have to say about. - Jonathan M Davis
