[Issue 4621] Destructors are inherently un- at safe

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4621



--- Comment #9 from Michel Fortin <michel.fortin at michelf.com> 2010-08-12 09:37:20 EDT ---
(In reply to comment #7)
> I think rather than prevent where these items should go, you should just not
> call the destructor when the struct/class is being destroyed by the GC.

One thing is that I fear it becomes too easy to write a destructor and then
forget the finalizer, which would results in leaks everywhere. So I think there
has to be something to remind people that they need a finalizer when they need
to dispose of some resource and the struct is allocated on the heap.

But just not calling the finalizer is still a better option than calling the
destructor during collection: a leak is less harmful than memory corruption.

Forbidding GC-allocated structs could be useful to make some RAII patterns
safer too. For instance, think of a struct representing a database transaction:
it should probably live on the stack, you certainly don't want it to be
garbaged collected. The compiler enforcing deterministic destruction would
improve program correctness for this kind of thing.

> I'd say you could even prevent what the finalizer contains, but it's too
> limiting for the compiler to assume what type of memory a reference is
> referencing.  My thought is simply that a finalizer is not safe, and a
> destructor is safe.  That at least gives a path for implementation (just mark
> your finalizer as @trusted, and it can be used in SafeD).

Whatever it is, I'm now of the opinion that the limitation should only apply to
SafeD. The limitation could be about dereferencing members and calling
functions that might dereference a member, or it could be that the finalizer
itself is not allowed to be safe.

Allowing non-dereferencing actions in the finalizer in SafeD would still allow
a few things, such as printing a "Hello I'm finalized!" message on the console
or updating a global variable (such as a counter of live objects). Nothing very
interesting though. But it'd also allow an empty finalizer to be @safe, which
might be useful if the presence of a destructor and the absence of a finalizer
prevents allocation on the GC-heap.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------