TDPL: Manual invocation of destructor

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> On Mon, 09 Aug 2010 15:46:27 -0400, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> Lutger wrote:
>>> Steven Schveighoffer wrote:
>>>
>>>> On Mon, 09 Aug 2010 08:28:38 -0400, Andrej Mitrovic
>>>> <andrej.mitrovich at gmail.com> wrote:
>>>>
>>>>> It's rather perplexing, isn't it? It states in TDPL:
>>>>>
>>>>> "After you invoke clear, the object is still alive and well, but its
>>>>> destructor has been called and the object is now carrying its
>>>>> default-constructed stated. During the next garbage collection, the
>>>>> destructor is called again, because the garbage collector has no 
>>>>> idea in
>>>>> what state you have left the object."
>>>> This seems totally wrong, what if an object has no default constructor?
>>>> The spec used to say (maybe it still does) that a destructor is 
>>>> guaranteed
>>>> to only ever be called once.
>>>  The spec still does, it is not updated since it describes delete, 
>>> not clear.  If you omit the default constructor, no constructor will 
>>> be called. Also not for the base classes even if they have a default 
>>> constructor. This looks like a bug.
>>
>> Yes, not calling the constructors of base classes is an implementation 
>> bug. If a class does not define any constructor at all, it has a de 
>> facto default constructor. If a class does define some constructor but 
>> not a parameterless one, it is a bug in the implementation if clear() 
>> compiles.
> 
> How can this be decided at compile time?
> 
> basic counter-example:
> 
> class C
> {
>    this(int x) {}
> }
> 
> // how do you statically disable this?
> void foo(Object o)
> {
>   clear(o);
> }
> 
> void foo(C c)
> {
>    auto c = new C(1);
>    foo(c);
> }

Sorry, I got things mixed.

> I always thought clear would simply overwrite the object with it's 
> default data as defined in the TypeInfo (i.e. before a constructor is 
> normally called).  Calling the constructor is absolutely wrong.  We 
> don't want to reset the object, we want to free it's resources.  
> Re-constructing it may reallocate resources *THAT WE JUST ASKED TO BE 
> DESTROYED MANUALLY*.  To say clear as defined is a replacement for 
> delete is complete fantasy.

Well this is my view as well and the original intent of clear(). The 
problem is, if someone defined a default constructor, they presumably 
have a nontrivial invariant to satisfy. I'm unclear on what's the best 
path to take.

Andrei