On Thu, May 01, 2014 at 01:37:28AM -0700, Jonathan M Davis via Digitalmars-d wrote: > On Wed, 30 Apr 2014 13:21:33 -0700 > Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> > wrote: > [...] > > 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.
+1. > > 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. [...] I'd like to hear an enumeration of those reasons as well. While in principle I agree with the sentiment to get rid of class dtors, I'm concerned about the rippling side-effects this will have throughout the rest of the language. Such as class members that are structs with dtors, which will mean that the struct dtors will never get called. Using another poster's argument: if dtors are used for resource management, then it's a bad idea to mix dtors with GC (i.e. classes). So in this sense I agree with getting rid of class dtors. But we have to consider what happens to the case where you stick a struct with a dtor into a class. I'm inclined to say that we should outright prohibit that, because again, the dtor (struct dtor this time) is used for resource management, and therefore shouldn't be mixed with a GC'd resource (i.e., classes). I find it unacceptable that the compiler will silently accept such a usage, and yet have no semantic guarantees (that dtor will run). This is the kind of behaviour I expect from C/C++, but not from D. Next thing you know, somebody is gonna start wrapping structs inside classes as a way of suppressing the dtor. I don't think that's the kind of thing the language should allow. I contend that it will do the language a great deal of good to outright ban such a kind of usage. (Structs with no dtors, OTOH, can be safely used as class members, obviously.) T -- It only takes one twig to burn down a forest.
