http://d.puremagic.com/issues/show_bug.cgi?id=4621
--- Comment #9 from Michel Fortin <michel.for...@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: -------