On 5/1/14, 3:22 PM, H. S. Teoh via Digitalmars-d wrote:
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.
No.
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?
We can't propose correctness at the price of getting work done.
So this kind of error-prone usage should not be
allowed by default. Was my logic really that hard to follow?
Your logic is flawed. I am sorry.
Andrei
