On 5/1/14, 7:30 AM, H. S. Teoh via Digitalmars-d wrote:
On Thu, May 01, 2014 at 01:37:28AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
While it's not good to rely on finalizers, they're good to have as
backup if the appropriate cleanup function doesn't get called like
it's supposed to. They're not as critical as they'd be in Java, since
we have structs, but I'd be disinclined to remove finalizers from D
without a really good reason.
[...]
I'd like to hear an enumeration of those reasons as well.
1. Most scarce resources must be released eagerly. GC collections occur
relatively rarely and are triggered by different signals (low on memory).
2. The notion of running the GC when one runs out of file handles or
sockets is terribly inefficient.
3. Destructors are odd - they will run in a different thread than the
one that created the object. They also are limited in surprising ways,
i.e. may not allocate memory or block on other threads directly or
indirectly.
4. Due to imprecision, there's no actual guarantee any given destructor
will end up running. Leaving a scarce resources at the whim of a
best-effort approach is poor design.
While in principle I agree with the sentiment to get rid of class dtors,
I'm concerned about the rippling side-effects this will have throughout
the rest of the language. Such as class members that are structs with
dtors, which will mean that the struct dtors will never get called.
Using another poster's argument: if dtors are used for resource
management, then it's a bad idea to mix dtors with GC (i.e. classes). So
in this sense I agree with getting rid of class dtors. But we have to
consider what happens to the case where you stick a struct with a dtor
into a class. I'm inclined to say that we should outright prohibit that,
That can't happen.
Andrei
