Why will the delete keyword be removed?

[Vladimir Panteleev]

On Thu, 15 Jul 2010 00:33:15 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> All classes have a state where all members are default initialized.

How is that state normally reached (for classes without a default  
constructor)?

>> It is my understanding that you are trying to add something to the
>> language which would destroy an object without deallocating it (and
>> deprecate everything that involves on-the-spot deallocation), in order
>> to allow creating simpler and more efficient garbage collectors.
>
> I'm not adding anything. I am removing a mistake that C++ made (i.e.  
> conflating destruction with deallocation). And the purpose is not to  
> assuage or help GCs. The only purpose is memory safety.

>> The
>> only correct solution seems to be to call the destructor, and mark the
>> object instance as invalid. The release version needn't do anything, the
>> debug version can stomp on the object's memory to make sure that any
>> code that attempts to access the object crashes quickly. (This is
>> practically the same as deallocation, as far as the user can see - the
>> difference lies in that the GC doesn't do anything immediately.)
>
> For safety there's no debug and release. It's either safe or unsafe.

So your goal is to prevent new objects from being allocated at the same  
address for the sake of memory safety?

If so, then something like this belongs in SafeD *only*, in my opinion. We  
have tools (stomping, valgrind, etc.) to allow catching bugs like these.  
"Memory safety", especially at the cost of performance, does not belong in  
a compiled language that allows pointer arithmetics.

> Adding a Boolean to each object to tell whether it was destroyed or not  
> complicates matters without bringing a palpable benefit.

I meant "mark the object instance as invalid" figuratively, not using a  
flag anywhere. ("Marking" would mean stomping on the object in the debug  
version to prevent further use of the object.) Now I understand that your  
goal is not to allow programmers to catch bugs, it's to stop the  
programmers from doing anything that might involve shooting themselves in  
the foot.

Your approach has the following problems:

1) As discussed, the objects are left in an abnormal state (T.init without  
any work done by constructors). I don't think you can construct such  
objects normally.

2) When an object was deallocated via "delete", assuming it didn't have a  
destructor that accessed the object instance, the object's memory was not  
being accessed. This means that if an object was swapped out, it wouldn't  
need to be swapped back in just to destroy it. Your solution undoes this.  
(Does performance actually count as a factor at all in your design  
decisions?)

However, I also noticed that your approach has an interesting advantage:  
after an object's memory is clobbered with T.init, it can be added to a  
free list for fast construction (when the GC doesn't detect any references  
if you want safety).

-- 
Best regards,
  Vladimir                            mailto:vladimir at thecybershadow.net