Destructor semantics

[Michel Fortin]

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
		}

	}


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/