TDPL: Manual invocation of destructor

[Steven Schveighoffer]

On Mon, 09 Aug 2010 21:52:10 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2010-08-09 21:20:31 -0400, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> said:
>
>> clear() would not subvert the type system.
>
> Oh sure it does!
>
> 1. You acknowledged yourself one of my argument a few days ago that if  
> the class has an immutable member it'll be wiped out. Someone else  
> somewhere could have a reference to that member, and it's value will  
> change which could cause bad things..

This is a good point.  But here is the thing -- when you are calling  
clear, you are saying "Nothing in this program is using this data any  
more".  The point of not actually deleting the memory is to 1) not throw a  
monkey wrench into the natural rhythm of the GC, and 2) to ensure any  
dangling pointers do not corrupt memory.  Essentially, if you clear an  
object, and then use that object, the behavior should be undefined.

Note that delete has the same problem, but by the time you reference that  
dangling pointer, it may have been reallocated, so you might be corrupting  
memory in use.

I think it's fine to have clear break immutability, since to call clear,  
and then to access the data should be undefined.

> 2. If someone somewhere has a reference to an object, clearing that  
> object is basically the same as replacing that reference with a  
> reference to a new, uninitialized object. This could break invariants of  
> any code still using that reference.

As any undefined behavior could.  If you don't want to cause this problem  
then either ensure your not using it, or don't use clear ;)

> In normal times, those invariants could be protected with judicious  
> usage of 'private', 'protected' or 'package' in the object (or something  
> more sophisticated), but all that gets subverted by clear().

clear is a replacement for delete.  Would you expect delete to keep  
invariants of dangling pointers alive?

> So clear() can have long-reaching effects (break program invariants) if  
> used at the wrong place, and it's difficult to protect against people  
> using it at the wrong place.
>
> I know for one thing that clearing any object used by the D/Objective-C  
> bridge is a potential crasher (if you call a function on a cleared  
> wrapper). I would suspect the same for QtD.

Undefined, undefined, undefined :)

-Steve