More radical ideas about gc and reference counting

[Walter Bright via Digitalmars-d]

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.