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.
