TDPL: Manual invocation of destructor

[Steven Schveighoffer]

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

> On 2010-08-10 08:11:21 -0400, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>> Undefined, undefined, undefined :)
>
> So we agree on that. That's exactly what I was trying to prove to  
> Andrei. Using clear() can break program invariants, break the type  
> system (immutable members) and so on, even though I admit it can be  
> useful at times.
>
> **** So why give it a so innocuous-looking name such as "clear" !! ****

I think that book has shipped.

> Call it destroy() at the very very least, and put it in a module where  
> no one will find it by accident and think it is safe for general use.  
> For instance, it could be made part of the GC API, allowing the GC to  
> adjust the memory block to avoid calling the destructor a second time  
> upon collection. GC.destroy() sounds like a good name for that kind  
> functionality.

delete is currently available whenever you want it and is twice as  
dangerous.  It might as well be in object.di.  I think that's where clear  
belongs too.

Hiding it from users is not the right thing to do.  Once you find  
something, you aren't going to forget where it is.  Maybe we can move it  
to a random module on each release ;)

Placing danger warnings around it on all sides, with a legal disclaimer  
you must sign in order to use it, and make IDEs highlight it in red is  
probably all that is necessary.  Disallowing it in safeD might be a better  
deterrent than naming it a certain way or putting it in an obscure module.

-Steve