Destructor semantics

[Jonathan M Davis]

On Wednesday, August 11, 2010 12:43:10 Michel Fortin wrote:
> On 2010-08-11 15:09:45 -0400, Jonathan M Davis <jmdavisprog at gmail.com> 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