On 2010-08-11 13:10:08 -0400, Jonathan M Davis <[email protected]> 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
[email protected]
http://michelf.com/
