Destructor semantics

[foobar]

Steven Schveighoffer Wrote:


> So if a struct has a class reference, it cannot clean it up?  What if the  
> class contains a struct that has an open file reference, and you want to  
> clean up that file immediately?  What if that class is private and the  
> struct knows that there are no other references to it?
> 
> Your "solution" doesn't cover any new ground, we already have the issue  
> that you cannot clean up or even access heap-allocated references in  
> destructors.  The problem is, you don't know from the type system that  
> they are heap-allocated, and the compiler cannot know what is owned and  
> what is not owned, so it can't make the call to restrict you.
> 
> What we need is a way to determine whether we can access those resources  
> or not in the destructor, and it has nothing to do with struct vs. class,  
> and everything to do with deterministic vs GC.  Making an artificial  
> distinction on class/struct lines doesn't help.  We have the same problem,  
> only worse restrictions (now I can't destroy a handle in a class on  
> destruction, I need to put in a struct layer around it).
> 
> -Steve

I see your point above. I feel that my approach is more structured. I think that at minimum the compiler should prevent (at compile time) any access to reference types from a class dtor. 
I can't imagine what can be your use case for allowing such access. It seems to me that any time you feel the need for one class instance to own a different class instance you should use a struct instead to convey that owned relationship.

Wouldn't you need an annotation system like the one suggested by Bartoz in order to properly implement the owned relationship for reference types?