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?
