Why will the delete keyword be removed?

[Max Samukha]

On 07/14/2010 10:43 PM, Andrei Alexandrescu wrote:

>
> There is no early failure with dangling pointers.

There is:

class A
{
     void foo() {}
}

class B : A
{
     override void foo() {}
}

A a = new B;
A a2 = a;
clear(a);
a2.foo();

If you reset the object state to .init, foo will succeed and the program 
will happily crawl on. If you zero out the object's memory, the call to 
foo will fail. I'd prefer the latter.

The same with an interface:

interface I
{
     void foo();
}

class A : I
{
     void foo() {}
}

void main()
{
     A a = new A;
     I i = a;
     clear(a);
     i.foo(); // would segfault
}

One more (rare but possible):

void bar()
{
}

class A
{
     void function() p = &bar;

     void foo()
     {
         p();
     }
}

void main()
{
     A a = new A;
     A a2 = a;
     clear(a);
     a2.foo; // would segfault
}

>
>> I'd probably want clear() to run the destructor and zero the object's
>> memory.
>
> No, because:
>
> class A
> {
> int x = -1;
> float y = 0;
> ...
> }
>
> You'd want that guy to be obliterated with the proper initializers for x
> and y.
>

Not that I fiercely disagree but ideally I'd want it to be obliterated 
to an invalid but easily recognizable state. It might help to discover 
dangling pointer errors early. Otherwise, leaving a destroyed object in 
a perfectly valid state may make debugging more fun than it needs to be.

In my world, clear() would run the dispose handlers, unset the memory 
block's BlkAttr.FINALIZE (if the object is on GC heap), call the 
object's destructor, destroy the monitor and zero the memory. I guess a 
call to rt_finalize could be used as part of this procedure.

Or something like that.