On Wednesday, August 11, 2010 12:43:10 Michel Fortin wrote: > On 2010-08-11 15:09:45 -0400, Jonathan M Davis <[email protected]> said: > > On Wednesday, August 11, 2010 11:33:54 Michel Fortin wrote: > >> 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. > > > > But couldn't the fact that a struct has a destructor make it so that it > > can't be > > declared anywhere but on the heap? The destructor itself could be what > > distinguishes them. I don't see a need for any other @attributes or > > whatnot to distinguish them. > > Sure, and now you can't use std.containers.Array as a member in a > Class, neither std.stdio.File, etc. Is there something left classes can > do?
This mess is just too complicated, and I'm getting more and more confused the more it gets discussed. I'll obviously need to study it closely, if I want to be able to understand it properly. Ideally, I'd be able to use structs on the heap and structs in classes with impunity. Their destructors get called when they leave scope or the class that their in gets destroyed (which may or may not be - though likely is - when it's garbage collected). Structs put directly on the heap obviously have trouble with how things are right now, though you'd think that they'd be able to have their destructors run properly as well. This needs to be sorted out in a manner that minimizes how much pain it causes for the typical programmer in their typical programming tasks. Destructors should not be this much trouble. - Jonathan M Davis
