On Thu, May 01, 2014 at 03:10:04PM -0700, Walter Bright via Digitalmars-d wrote: > On 5/1/2014 3:02 PM, H. S. Teoh via Digitalmars-d wrote: > >I'm confused. Andrei's original proposal was to deprecate class > >dtors, with the view to eventually getting rid of them altogether. If > >indeed that's going to be the case, then wouldn't that mean that > >field dtors won't be invoked either (because otherwise, how would you > >know when to invoke a field dtor?)? > > > >Without a clear definition of who is going to clean up those fields > >and invoke their dtors, it would seem to me that having fields with > >dtors in a class (once class dtors no longer exist, according to > >Andrei's proposal) will be a dangerous thing to do, since the very > >guarantee by having a dtor in the first place (it will get called to > >clean up when the struct goes out of scope) is broken. If so, what's > >the point of having a dtor in the first place? It becomes no > >different from the manual cleanup that you have to do in C. > > The thing is, GC is a terrible and unreliable method of managing > non-memory resource lifetimes. Destructors for GC objects are not > guaranteed to ever run. If you do have struct with a destructor as a > field in a class, you've got, at minimum, suspicious code and a latent > bug.
Exactly!!! This is why I said we should ban the use of structs with dtors as a field in a class. Isn't the D philosophy to be correct by default, and only allow potentially wrong/error-prone code if the user explicitly asks for it? So this kind of error-prone usage should not be allowed by default. Was my logic really that hard to follow? T -- "Hi." "'Lo."
