More radical ideas about gc and reference counting

[H. S. Teoh via Digitalmars-d]

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."