Destructor semantics

[Lutger]

Michel Fortin wrote:

> On 2010-08-10 17:23:39 -0400, foobar <foo at bar.com> said:
> 
>> Steven Schveighoffer Wrote:
>> 
>>> That doesn't help.  deterministic destruction is not a struct-vs-class
>>> problem, its a GC-vs-manual-memory problem.  A struct on the heap that is
>>> finalized by the GC has the same issues as a class destructor.  In fact,
>>> struct destructors are not currently called when they are heap-allocated
>>> because the GC has no idea what is stored in those memory locations.
>>> 
>>> -Steve
>> 
>> Let me add to the above, that the GC should NOT manage structs
>> allocated on the heap. structs should only provide deterministic
>> semantics.
> 
> That's an interesting idea. By allowing classes only on the
> garbage-collected heap, and structs only in non-garbage-collected
> situations, we do indeed simplify the destructor problem. A struct
> destructor is always deterministic and a class destructor is not.
> 
> Unfortunately, that's not exactly where things are headed.
> 
> I'm not sure what's best, but I'm starting to believe that without this
> simple rule we'll have to add the complexity of having two kind of
> destructors in the language... would this make sense:
> 
> class Test {
> 
> ~this()
> {
> // disposer destructor
> // called by deterministic destruction
> // can access GC-managed members safely
> }
> 
> ~~this()
> {
> // finalizer destructor
> // called during garbage collection
> // cannot access GC-managed members (might be dangling pointers)
> // unavailable in SafeD because of the dangling pointers
> }
> 
> }
> 

This is what I proposed, but the other way around and the semantics of ~~this 
implemented by an interface. If we keep ~this as the finalizer, the language 
need not to change so it will not impact existing code too much. Especially 
because delete will go away. It is not too bad, we don't need to do everything 
with it like .NET has to. You can always wrap a class in a struct that will 
destroy it, or use reference counting like File does. I think that should be 
preferred.