Destructor semantics

[Michel Fortin]

On 2010-08-11 13:10:08 -0400, Jonathan M Davis <jmdavisprog at gmail.com> said:

> The more this whole issue gets discussed, the less it seems like I know about
> the issue. It's just too complicated to be immediately understandable.
> Personally, I think that the very fact that it's possible to access references
> which are no longer valid in a class destructor (and not only possible but
> _easily_ as well) makes it so that class destructors should be disallowed in
> SafeD. They just don't sound safe. If you really know what you're 
> doing, you can
> use them, but other than that, forget it. That sounds precisely like why SafeD
> exists in the first place.

I've made a bug report about destructors and SafeD, if anyone wants to 
add to it.
<http://d.puremagic.com/issues/show_bug.cgi?id=4621>


> Not to mention, it's looking more and more to me like if you want any kind of
> reasonable destruction going on, you need to be using a struct on the stack
> anyway. I'd suggest not only disallowing class destructors in SafeD but also
> disallowing structs with destructors on the heap in SafeD. It's just too messy.

I'm not too sure that'll work very well. I think a better solution 
would be to have a way to distinguish between a struct that can be put 
on the GC heap and one that cannot. A struct that cannot go on the GC 
heap make it safe to access GC-managed members in its destructor, and 
thus can have a @safe destructor.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/